Microsofts .NET Framework is so good for so many things, but its a big "gotcha" for security! .NET is big on security and everything not executed on the local drive is subject to its rules. Network (and internet) executables are what they are trying to protect against - and for good reason; with Microsoft's perceived track record on flaws and security, the more potential malware you can stop at the perimeter (i.e., its execution), the less you have to worry about it exploiting a flaw or running unbeknownst to the end user.

However, the .NET Security Configuration tool is not easiest to work with. First the documentation is TERRIBLE - look for blogs and deeper MSDN articles (http://blogs.msdn.com/shawnfa/archive/2004/12/30/344554.aspx, http://blogs.msdn.com/shawnfa/archive/2005/07/27/443975.aspx, and http://msdn2.microsoft.com/en-us/library/4z8tf9wx(VS.80).aspx are a few) for the real scoop and real-world scenarios. Also, each network area is broken up in it almost exactly like your browser (i.e., My Computer, Intranet, Internet, Trusted Sites, Untrusted Sites, etc.), and your machine (in the CLR) will first figure out where the application falls into these categories. Thus, first you must figure out which one your network application falls into (i.e., where the .NET Runtime will say it belongs). For most network apps, this would be the "Intranet" group. If you put a security policy into the Local Computer node and its a network app, the policy will never be honored. Second you must either authorize the Application itself (and any child apps) or the directory. We like the second one as it is much simpler (though probably not quite as secure since another "malware" app could come into the directory or even insert itself in place of the app - unlikely unless you program for Microsoft or Symantec). Here is a sample bat script (you must run it for each version of .NET since they have separate security setups

@echo off

:V2Check
IF EXIST %windir%\Microsoft.Net\Framework\v2.0.50727 GOTO v2
GOTO v1Check

:v2
c:
cd %windir%\Microsoft.Net\Framework\v2.0.50727
CasPol.exe -pp off -machine -remgroup "X Share"
CasPol.exe -pp off -m -ag 1.2 -url file://x:/* FullTrust -n "X Share"
copy config\security.config config\security.config.default

:v1Check
IF EXIST %windir%\Microsoft.Net\Framework\v1.1.4322 GOTO v1
GOTO Exit

:v1
c:
cd %windir%\Microsoft.Net\Framework\v1.1.4322
CasPol.exe -pp off -machine -remgroup "X Share"
CasPol.exe -pp off -m -ag 1.2 -url file://x:/* FullTrust -n "X Share"
copy config\security.config config\security.config.default

GOTO Exit


:Exit

It is a common fallacy that computers "think" in numbers - they do not. Many others believe they process binary - 1s or 0s - and this would be correct. But have you ever stopped to think how then they "convert" those numbers to binary to story and process mathematics? While this is a huge subject and one more suited for a Computer Science class than a blog, we got on this subject in depth when modifying a client's source code. You see, the previous programmer was using several numeric types interchangeably and when the exact same inputted numbers were compared they did not "match", and since this was a financial application it was more than a bit critical that they balance! Long story short, many of the various numeric datatypes look at and apply different memory reservations and processing to the same number - the most common of these is how each one handles fractions (i.e., non-whole numbers) since they must be ultimately represented to the processor as a binary. For any junior programmers or "script-kiddies" out there, simply ALWAYS USE THE SAME NUMERIC DATATYPE FOR THE SAME PROCESSING! Lots of great stuff out there on how these datatypes, but here are a few links for .NET that get more into how .NET's particular datatypes are handled:
http://www.yoda.arachsys.com/csharp/floatingpoint.html
http://www.yoda.arachsys.com/csharp/decimal.html

With all of the abstraction in .NET and with all of the other "higher-level"" protocols such as SMTP present, it is a little amazing there is no support for FTP natively. Instead you need to access the Wininet api directly as with the following code:

Public Class FTP
EntryPoint:="InternetCloseHandle")> _
Public Shared Function CloseConnection(ByVal _
HINet As Integer) As Integer
End Function
EntryPoint:="InternetOpenA")> _
Public Shared Function Open(ByVal _
sAgent As String, ByVal lAccessType _
As Integer, ByVal sProxyName As String, _
ByVal sProxyBypass As String, _
ByVal lFlags As Integer) As Integer
End Function
EntryPoint:="InternetConnectA")> _
Public Shared Function Connect( _
ByVal hInternetSession As Integer, _
ByVal sServerName As String, _
ByVal nServerPort As Integer, _
ByVal sUsername As String, _
ByVal sPassword As String, _
ByVal lService As Integer, _
ByVal lFlags As Integer, _
ByVal lContext As Integer) As Integer
End Function
EntryPoint:="FtpPutFileA")> _
Public Shared Function PutFile( _
ByVal hFtpSession As Integer, _
ByVal lpszLocalFile As String, _
ByVal lpszRemoteFile As String, _
ByVal dwFlags As Integer, _
ByVal dwContext As Integer) As Boolean
End Function
EntryPoint:="FtpGetFileA")> _
Public Shared Function GetFile( _
ByVal hFtpSession As Integer, _
ByVal lpszRemoteFile As String, _
ByVal lpszNewFile As String, _
ByVal fFailIfExists As Boolean, _
ByVal dwFlagsAndAttributes As Integer, _
ByVal dwFlags As Integer, _
ByVal dwContext As Integer) As Boolean
End Function
End Class


Then you can access the API by calling the code as follows:

Try
' Instantiate a new FTP object
myFtpClient = New ftp
hInetSession = myFtpClient.Open( _
"WebClientFtpTransfer", 0, _
vbNullString, vbNullString, 0)
' Check to see if Internet session was
' successful
If hInetSession = 0 Then
Throw New System.Exception( _
"Could Not Connect to the Internet")
End If

' Now connect to the FTP client (include login
' if necessary)
hFTPSession = myFtpClient.Connect(hInetSession, _
ServerName, 21, FTPLogin, FTPPassword, 1, _
0, 0)
' Check to see if Internet session was successful
If hFTPSession = 0 Then
Throw New System.Exception( _
"Could Not Connect to the FTP Server:" & _
ServerName)
End If
' Now post the file
ftpFunctionRC = myFtpClient.PutFile(hFTPSession, _
strFileName, strFileName, 0, 0)

' Get the results from the remote server
If ftpFunctionRC = 0 Then
lblStatus.Text = "FTP Transfer Successful"
Else
Throw New System.Exception(M _
"Could Not Transfer File: " & strFileName)
End If
Catch ex As Exception
lblStatus.Text = "ERROR UPLOADING FILE " & _
"VIA FTP" & vbCrLf & ex.Message
lblStatus.ForeColor = System.Drawing.Color.Red
End Try
' Close the connection
myFtpClient.CloseConnection(hInetSession)

Read More »

A large part of our effort at revamping our organization has been to get tools that are not only efficient, but work with each other to serve the customer.  Since our main work is in development, we obivously need to be able to document both our work for the customer and the customer's responses (and ours) to any issues with that development.  So we've been looking at, testing, and dogfooding many Help Desk / Bug Tracker applications including: Gemini (http://www.countersoft.com/), HelpSpot (http://www.userscape.com/products/helpspot/) , FogBugz (http://www.fogcreek.com/FogBugz/), HelpDeskPro (http://www.helpdeskpro.net), Polar Help Desk (http://www.polarsoftware.com/products/servicedesk/index.asp), BugTracker.NET (http://www.ifdefined.com/bugtrackernet.html), Libernum (http://www.liberum.org/), and ZenTrack (www.zentrack.net).

First, we do have some basic issues we need to deal with.  First, Help Desk software does not necessarily mean Bug Tracker / Software Development Tool.  Ian Landsman makes this point in his blog (http://www.userscape.com/blog/index.php/site/comments/fogbugz_vs_helpspot_as_a_help_desk/), but does not quite finish the thought.  HELP DESK SOFTWARE IS INHERENTLY CUSTOMER/PEOPLE-CENTRIC WHILE BUG TRACKING/DEVELOPMENT SOFTWARE IS INHERENTLY SOFTWARE-CENTRIC.  Any tool that can accomplish both of these together is VERY expensive.

So the next question is: Does a Help Desk have the ability to interact with a Bug Tracker ?  Is it out-of-the-box ready to do this?  For every one we looked at, the answer was a resounding "NO"!  Here is a more detailed list of our requirements:

1. Is it a Help Desk with all that implies (Customer-centric. Multiple Clients, Public Submissions, EMail responses and ticket updates, Time/Issue Tracking, Customizable Issues and Support Assignments, Knowledgebase, etc.)?
2. Is it a Bug Tracker / Development Software with all that implied (Software-centric, Multiple Projects, Versioning, Respository integrated, Notification and Viewing of Updates including new releases and patches, scheduling, etc.)?
3. If the product fits into either of the first 2 categories, can it do the other?  If not, can it integrate with another?
4. If the answer to 3 is no, can it be made to integrate with a minimum of fuss and a maximum customizability / extensibility?  If so what is the nature of the API or interface?

There was only one product in our list that appeared to work: CounterSoft's Gemini.  We've been following this product off-and-on for 2 years and have even used it in production for a while - then dropped it.  However, a look and test drive of the newest version (2.2.x) incorporates many of the features we need.  While it is primarily for Bug / Software Tracking, Gemini has recently incorporated many extensible parts to make it customizable to a point that we believe we can get both out of it with a minimum of programming - the fact that it is written in .NET means we should be able to quickly get it up to speed.  We post how it goes and if you have other options you use, leave a comment!