Monthly Archives: January 2010

Nasty, Nasty x64 and the AnyCPU Option

Filed under .NET, VB Feng Shui

At one point a while back (while I was still working for my previous company), we had “support for x64” handled down as a request for an interim version.

I thought, “No sweat”. Grab a few alternative prerequisite MSIs, determine the bitness of the processor you’re on in the install (InstallShield has the functionality built in), and just fire off the appropriate preqs. Our actual application is 32bit, and we had no intention or need to compile as 64bit.

Well. A few clicks later and the install was built and deployed to a test machine.


Initial sample database didn’t get deployed properly.

Ok, why not. Well. Long story short, the application couldn’t find a registry key setting. But I hadn’t changed anything about the registry.

Lots of digging through verbose install logs later, and I discovered that the installer was, on a 64bit OS creating registry keys under the key  HKEY_CURRENT_USER\Software\Wow6432Node whereas when my application when to get the registry key, it was looking in the normal HKEY_CURRENT_USER\Software\ key.


First, what the hell was this Wow6332Node? Obviously it’s some kind of “compatibility” bit for running 32bit apps under a 64bit OS. And that’s exactly what it is.

Ok, my Installer is InstallShield, and it’s a 32bit app (even if it can install 64bit packages), so that explains why it was writing the key to that Wow6432Node, but why wasn’t my application reading it from there?

A little digging later, and I found this option buried in the “Advanced Compiler Settings” panel of the “Compile Options” tab of the Project’s properties.


See that AnyCPU setting? When set to AnyCPU, the JIT compiler will dynamically compile your .net dll as either a 32bit or 64bit dll, depending on the process that loaded it.

Obviously, on a 32bit OS, all the processes will be 32bit, so everything’s 32bit.

BUT, on a 64bit OS, things get nastier.

If the DLL runs under a native code 32bit process, it’ll get compiled as 32bit x86 code and run under the Wow32 (Windows On Windows) layer. This explains why the DLL that acts as an AddIn to Word worked just fine. Word is a native 32bit process, so the DLL was ending up executing as 32bit too.

However, the little utility app that creates our initial database was a .net application, and it was set to AnyCPU.

That meant that when IT loaded our DLL, the DLL ended up JITed to 64bit code (because the utility app was set to AnyCPU, so it was JITed to 64bit code because it was a base process and was running under a 64bit OS.

Case closed.

Short version of the story. Since tracing all this down, I’ve learned that for VS2008, the .net team decided to change the default of that option from x86 to AnyCPU, and then, in general, that has been regarded as a bad thing to have done.

The default will be changed BACK to x86 in 2010 apparently, but until then, unless you REALLY need to compile code for AnyCPU, be sure to switch this option back to x86!

Hunting Down a Bogus IP

Filed under Networking, Troubleshooting

I was working on a server issue this morning when I ran into something strange. I could no longer access a server that had been running for quite some time without any problems.

I tried a PING and got back an IP address for the server that made no sense at all. It wasn’t even part of my local IP range!

So I did all the normal stuff:

  1. Checked my HOSTS file

No joy. A ping was still returning the same bogus address.

So I checked my server’s DNS service. Not even an hit of that address.

Hmmm. So, where the heck was it coming from? A little googling didn’t turn up much, but eventually, I read a blog post that made an offhand mention of WINS.

Now, I don’t really know all that much about WINS. Just never had a reason to, I suppose. Mostly, I’ve always relied on and stuck with plain DNS. But, Ok, I’ll check it.

Go over to my server, and load up the WINS app (it’s under Admin tools)


The left hand window was completely blank. It took a second to realize I had to “query” to retrieve the WINS records, they aren’t automatically just shown.


And AHA! There, in the result list of “Active Registrations” was the bogus address for my server. (I’ve already removed it in the image below, but it was in the highlighted column).


Case closed. I’m still wondering what changed that suddenly, WINS was being used to resolve the server name when it must have not been before. The only thing I can think of is changing internet providers to Verizon FIOS from Time Warner Cable, and the resulting swap out of the main incoming router.

Granted, for a seasoned network guy, this is likely old hat. But for a software dev who only moonlights as a network guy, it might be some useful information!

Getting PHP Up Quick Under IIS 7 and Win7 64

Filed under Web

I had a need over the weekend to do a little PHP work. Now, I’m no expert in web anything, most of my time has been spent building nice happy fat client apps <g>. But, when I’ve needed to do a little web tinkering, my host ( pretty much supports everything, so I’ve just uploaded my files and had at it.

However, this time, I wanted to get things running locally, to avoid all the upload/download hassles.

A few google searches turned up the Microsoft Web Platform Installer.

Wow! Something other than Office, VS and SQLServer that Microsoft has done right!

It took a few minutes to run through, and I had to tweak the PHP.INI file a bit (using the instructions here), but, all told, I had a PHP 5.2 installation fully operational under a local IIS7 server in, oh, 10 minutes.

It the Web Platform Installer can install a lot of other stuff too. CMS, SugarCRM, DasBlog, and a bunch more.

Definitely worth the download!

Merging Assemblies, the Easy Way (part 1)

Filed under Code Garage, Utilities, VB Feng Shui

image Recently, I ran into a need to make use of the Mono.Cecil.dll library from a .net application I was working on. Cecil is a fantastic little project under the Mono project that allows you to interrogate an existing .net assembly (EXE or DLL file) and retrieve all kinds of information about the assembly, from the resources embedded within it to the classes and methods defined, and much more. You can even alter the contents of the assembly and write the new version back out to disk!

The thing is, Cecil comes prebuilt as a C# assembly (a DLL file), and I really did not want to have a second file required for this particular application (it’s just a little command line utility).

My first take was to use Oren Eini’s excellent concept of an assembly locator. My idea here was to embed an assembly as a binary resource, then, when requested, read that resource into a stream, load the assembly from the stream, and resolve references to it via the assembly locator.

I’m still working on that concept, because I think it’s a clever and convenient solution to the problem, but, in researching that, I happened to remember the even easier (as in, no code required at all!) solution of using ILMerge.


If you haven’t already discovered it, ILMerge is a Microsoft research project in the form of a single command line EXE utility, that can “merge” any number of .net assemblies with a “target” assembly, and produce either a .net DLL or EXE output file.

There’s a really good article on CodeProject describing the general use of the program. There’s even a GUI (Gilma) for it.

Automating ILMerge

What the article doesn’t go into is automating the ILMerge process. After all, you won’t want to manually run that command line utility every time you build your application!

The good thing is, it’s trivially easy to automate as long as you take care of one critical step.

  • First, download and install ILMerge from the link above.
  • Once it’s installed be sure to copy the ILMerge.exe utility to somewhere on your path (or add the folder it’s in to your path).
  • Then, grab the Mono.Cecil.dll file (or whatever DLL it is you want to merge into your main project EXE). Put it in the root folder of your project.
  • Go ahead and set a reference to that file, so you still get all the .net intellisense goodness, but be sure to set the Copy Local property for the reference to FALSE (after all, you don’t want to copy this DLL to the output folder along with the application if you don’t actually need it, right?)


  • With that done, you MAY want to mark the DLL you’re embedding as “included in project” from the Solution Explorer.

image If you do this, however, make sure you also set the Copy to Output Folder to “Do not copy” (that’s the default though so it should already be set).

The Tricky Part

One limitation of ILMerge is it that it can’t alter the target assembly “in place”. This means that, for instance, if you want the final resulting executable file name to be called GenerateLineMap (my utility), you can’t have VS compile the assembly to that name. You’ll need to use some other name for the initially compiled assembly.

On the Application tab of the project properties you can change that name, like so:


I just added “-Interim” to the Assembly Name.

Now, go to the compile tab of the project properties and click Build Events


Insert this as the POST BUILD EVENT

ilmerge /target:winexe /out:”$(TargetDir)$(ProjectName)$(TargetExt)” “$(TargetPath)” “$(ProjectDir)Mono.Cecil.dll”

Notice that the OUT parameter specifies the output file name via the $(ProjectName) variable (which is still “GenerateLineMap”) while the first assembly to merge is specified using the $(TargetPath) variable (which is the full filename of the output assembly, including the “-Interim”).


EDIT: Important note: Notice the /target:winexe option. You’ll need to change that as appropriate depending on the type of exe you’re building. In my case, I had a console app where this needed to be set to just /target:exe. Setting it to /target:winexe caused all of the console output functions to just do nothing, which threw me for a bit!

Now, just rebuild the solution and you should see two resulting EXE files in your output folder, one with the “–Interim” (which is the version WITHOUT the embedded Mono.Cecil.DLL file or whatever DLL you’ve chosen) and one WITH the embedded file. As a final cleanup, you may want to add an additional Post build step to remove the “*-Interim” files.

To test, just make sure you DO NOT have the embedded DLL anywhere on the path or in the same folder as the exe and run the exe. If everything went right, your app should work exactly the same as if the embedded DLL was included externally with the app!

Now, your application is back to being a single EXE to distribute, and it was built completely automatically by Visual Studio.


You knew there had to be some, right?

The first is that if the dll to embed contains licensing information, it might not work properly after being embedded. I don’t have any DLLs like that to test with, but I’ve read reports about the problem at various sites on the internet. Just something to be aware of.

Second, trying to replace the originally named exe with the newly built one results in VS not being able to debug the exe in the IDE (it throws a message about the assembly manifest being different from what was expected). I haven’t worked that issue out yet. What this means is that you might need to leave any references set to “Copy to Output Folder” while debugging, and not replace the original compiled assembly, just ILMerge it into a new assembly name.

Windows 7 and Vista GodMode

Filed under .NET, Vista, Windows 7

If you haven’t already checked it out, definitely head over to Tom’s hardware for their article on setting up “GodMode” in Windows 7 (apparently it works in Vista too, dang, wish I’d known that).

Basically, you create a folder somewhere, then rename it to


When you do, that folder becomes a “virtual folder” full of (on my system anyway) 278 links to virtually every administrator type function you might ever want to jump to on a Windows Machine. Here’s a sample screenshot:


Very, very cool indeed.