IBBoard

Section: Windows

If you want to develop .Net 2.0 applications using System.Windows.Forms on Windows then you need Microsoft's Visual Studio 2005 applications. Although I got Visual Studio.Net 2003 through University, I didn't feel like shelling out the stupid money that 2005 would have cost. Instead I downloaded the free and cut-down Visual Studio 2005 C# Express application and ran it in Windows under VirtualBox.

The problem

While the Express version was slightly feature limited, the main problems did not stem directly from the cut-down. Despite spending my working day taking advantage of the many useful features of Eclipse, I knew most IDEs weren't quite so feature rich. Instead the main problem was, slightly ironically, my development set up and Microsoft's security lockdown on non-local code.

As part of my VirtualBox setup I shared my development folders as VirtualBox shares. This meant I could then remove any network interface from Windows while still having one common location for source code - my main Linux disks, rather than a virtual disk. The down side is that .Net has a security framework in place that puts different levels of trust on different applications. Local apps have full trust, Intranet apps have slightly less trust and so can't access the local disk, and so-on.

When I finally got past the undescriptive errors that were triggered in a static constructor (which appear to have been the same issue) by not accessing that code, I got the following error in my error box:

Seemingly the .Net security was quite happy for me to create a FileDialog, but not to set its title. Oddly it decided I couldn't set the dialog's title because of insufficient I/O permissions. The fight was now on to work out how to get it to let me have sufficient permissions.

The existing solutions

There are various other solutions available on the Internet, but none of them worked for me. I tried adding full trust to a single share, but it could never find my share. I tried just fully trusting the Local Intranet group, but that didn't work either.

Every setting I tried through the Admin Tools for .Net didn't seem to make a single bit of difference - my application still wasn't allowed to set the title on a FileDialog because of system security permissions on file I/O from Intranet apps to the local disk. My remaining options were to keep copying the code backwards and forwards between the share and the virtual Windows disk, or to find some way to build the debug version on the local disk, just like I could with the Release version, then everything would be smooth.

The final, successful solution

After posting on the MSDN forums and being told it might be my working directory setting (to which the answer was "no, that just changes the directory that the app thinks it is working from, not the directory that code is compiled and executed in") I finally found the solution myself.

Although Visual Studio Express lets you set the build directory for the Release code, it didn't seem to have a matching option for the Debug code. Examining the .csproj file for the project revealed the relevant setting. The file itself is just an XML file, so editing only requires Notepad.

The offending section of the .csproj file was the <OutputPath> tag under the following:

The value of the <OutputPath> tag for "Release|AnyCPU" was set through the project properties, but for debug it was set and not changable through the Visual Studio editor. If this value could be changed to an absolute path on the local drive then the problem should be solved as the build would take place on the local drive and there should be no "remotely executed app" issues.

The solution was simple - replace:

with my desired string:

Once that was done then Visual Studio will happily build my code from the VirtualBox share on the local (virtual) C drive and execute it with full local permissions, allowing me to debug the System.Windows.Forms side of the application.

The main point that I took away after this run-around was "If the interface doesn't let you do basic and simple things, see if you can just hack it in there directly."