Skip to content
David Cumps
DevDays 2004 Belgium: .NET Framework for Sys Admins

DevDays 2004 Belgium: .NET Framework for Sys Admins

Originally published on my old blog at cumps.be on February 10, 2004.

Next was Tim Sneath (day 1), with a two-part session about .NET for sysadmins.

Tim Sneath presenting .NET for sysadmins

This is actually a session from the IT Pro track, but there were a lot of developers in there.

In the first session he explained about everything the .NET framework is and does, along with some nice demos, from which I’ll give some commands.

First the basic stuff:

csc file.cs              REM compile an exe
csc /t:library file.cs   REM compile a dll
csc /r:yourdll file.cs   REM compile an exe with your dll referenced

Then something nice:

ildasm yourapp.exe

This tool gives a nice overview of the generated IL and the metadata. I totally get the concept of why there is no more DLL hell.

The metadata includes the version number of your references, along with a possible public key. Which makes sure only your DLL gets run, and no trojan DLL someone else put in there.

Something else that got explained was signing.

First you generate a private/public key pair with:

sn -k key.snk   REM create your key pair, keep it safe!

Then you put it in your assembly and you sign it, and that way it can get a strong name.

Some random handy commands I noticed were:

pushd .   REM store the current dir
popd      REM return to the dir
start .   REM open the current dir in explorer

Now the GAC was explained. This is kind of a global assembly storage place, the System32 of .NET if you like.

Some funny things I saw were that he got CommandBar and BandObjects in there ;)

One other useful tool is ngen.

Your code always gets JIT-ted when run, this is no problem for servers, which stay on for a long time. But for a workstation and a Windows Forms app, this could make the startup slow. So therefore we generate an image, in native code. This is stored in the GAC as well, this makes your code start up a lot faster. And your app doesn’t need a Strong Name for this.

ngen yourapp.exe
ngen yourdll.dll

You could do this with your installer after deployment.

After this, it was lunch :p Sandwiches and orange juice.

Then back to Tim Sneath for part 2.

Tim Sneath in part 2 of the session

The most important thing I got here that isn’t on the slides is that users randomly choose Yes or No when prompted for ActiveX controls. Depending on what mood they’re in.

It was mainly about deployment and security in this session. How you can easily deploy your apps, with an installer, from a fileshare or from the web.

It showed the ease of XCOPY, along with recommending MSI.

Something that I found weird was, when you execute an exe locally and it doesn’t find all required DLLs, it won’t start. When you run it from the web, it’ll start and throw an exception when it can’t find the DLL when it dynamically wants to load it. Which, if unhandled, can make your app crash. Why not check for all required DLLs before running? Doesn’t an HTTP HEAD request do the trick to check if it’s there or not?

That was all for the .NET for sysadmin sessions.

Next one was about ASP.NET, also by him :p

You May Also Like