The Morning Brew

One of my longest standing pet hates with desktop software developed in .NET relates to the almost inevitable security exception that will occur if you attempt to run it from a network share. Its always one of the first things I notice about software, as I often download and unzip software onto my desktop (which on my work machine is located on a network share) and then attempt to run it in place. Many large and quite impressive pieces of software that get distributed as .ZIP files rather than installers suffer this plight, and a lot of them don’t handle the exception well (One that springs to mind was the much heralded release of NDepend 2.0).

The good news is that this anguish may well be about to come to an end, as Brad Abrams requests feedback about the .NET teams possible plan to make network shares trusted. As he mentions, there really is no good reason not to trust a network share for running managed .NET code – there is no such protection for unmanaged code, and there is little or no way a normal user would be aware of which is .a NET EXE and which is unmanaged EXE.

To answer Brad’s Questions:

A) Have you ever run into this limitation (a security exception when running a .NET application from a network file share)?

I frequently experience these issues – I tend to use this problem (and if its been worked round in the application) as a yard stick as to how well written the application is.

B) How often do you use network file shares for deploying applications (managed or otherwise)?

Most of my development is web based, however for utilities written for in house use we tend to distribute them on a network share – being able to run these in place would be a great help, as updating them would be easier.

C) If you think we should make this change, when would be a good time? Is it something we should do sooner in a service pack of the .NET Framework or later in a full release of the framework. Note, we are DONE with .NET Framework 3.5, so there is zero chance it is getting in that release.

From my point of view a patch as soon as possible, and have it included in the next release of the framework – Since this is a relaxation of the current restriction, I can’t see that it would cause any more problems in terms of support of existing application, as a reduction of the support incidents caused by this issue would reduce.

D) Can you ask your local network admin what they think of this issue? Would they be in favor of this sort of change? If so, when?

This change should simplify deployment – allowing Managed EXE to run from shares should mean that local disks can be more locked down as there would be no need to copy programs locally to run them.

All in all, I’m very much in favour of this change – It will level the playing field, give a more consistent user experience, and reduce the problems people have with winforms applications.

Comments Off on Untrusted Network shares

When you first request a page from the an ASP.NET application, the .NET framework takes the ASPX file and generates code to actually execute the page. This code is then compiled by the framework and the results of the compilation are stored in the Temporary ASP.NET files directory within the framework directory (usually located in c:\windows\Microsoft.NET\Framework). When the ASPX of the compiled DLL changes this code is re-generated and recompiled.
On a server that hosts lots of ASP.NET applications this store of temporary compiled code can occupy a considerable amount of space. On machines with a limited amount of space on their OS partition this can begin to cause problems. Thankfully the ASP.NET framework does allow the location of this directory to be specified as a custom location.
As with most server wide settings you need to make a change to the Machine.Config (for .NET 1.1) or Machine wide web.Config (for .NET 2). The crucial part of the configuration is the Compilation element within system.web. The compilation element has an optional attribute called tempDirectory that allows a new directory location to be specified overriding the default setting of %FrameworkInstallLocation%\Temporary ASP.NET Files.

   
      ...
   

One thing to watch out for when making this change is the file permissions on your new Temporary ASP.NET files – copying the permissions from the original location will do the trick nicely.

3 Comments »

Today I encountered a strange problem with IIS6 restarting without notice on a server that had recently had the .NET Framework 2.0 installed on it. In our particular case the problem was made worse by the fact that the IIS restart was unsuccessful leaving the server in a some what crippled state. We traced the problem to clicking on the ASP.NET in the IIS Management MMC, not making any changes to the settings, then clicking OK on the properties dialog.
Usually making a change to the version of ASP.NET will cause a restart of IIS (and there are alternative ways that avoid the restart), however in this case it seems as though just viewing the tab and then clicking OK was enough to cause ASP.NET to restart the IIS Service. I’ve still not discovered precisely why this is happening, but for the time being I wanted to implement a work around to avoid the problem by disabling the ASP.NET Tab.

I thought doing this would be easy, after all enough people seem to have problems with the tab not being there. Common causes of the tab being missing seem to be running the IIS MMC on x64, or having installed an earlier beta of .NET 2.0. The fixes in most cases seem to be modifications to the registry or re-running aspnet_regiis -i to re-register ASP.NET.

While it is possible that by fiddling with the registry I could break the ASP.NET tab that didn’t seem to be a good solution, so I carried on digging. It turns out that the ASP.NET Tab is implemented as an MMC Snap-in extension, and can be disabled with two clicks of the mouse once you’ve found the setting. So, to disable the ASP.NET tab within the ASP.NET management MMC:

1. Start the MMC console (Start > Run > ‘mmc’ OK)
2. Open the IIS management mmc (Console > Open > ‘%windir%\system32\inetsrv\iis.msc’ OK)
3. Edit the Snapin Settings (Console > Add/Remove Snap-in)
4. Choose the Extensions Tab, and disable the ‘ASP.NET Management Extension’ by unticking ‘Add all Extensions’ and the unticking the ‘ASP.NET Management Extension’.
5. OK the changes and then save the console (Console > Save )

Now when you start the IIS Manager the ASP.NET tab won’t be there.

Sadly the tab is still there in the Computer Management MMC (Computer Management > Services And Applications > Internet Information Services), and looking at the computer management MMC in the same way as above does not yield the same choice of Extensions, so if anyone knows how to influence Computer Management in the same way, please let me know!

5 Comments »