Dotfuscator “Could not find compatible version of ildasm”

Question

Have any of you had this problem before?

I'm trying to obfuscate a solution written in C#/.NET 3.5 on Visual Studio 2008 SP1 on a machine running Windows 7 Professional SP1, and keep getting the same error when using Dotfuscator Community Edition

Could not find a compatible version of ildasm to run on assembly (valid path to solution output exe). This assembly was originally built with .NET Framework v2.0.50727

I've tried Googling and nothing much has helped so far (either that, or my Google-Fu is failing me).

I've tried re-installing the Windows SDK, and re-installing Visual Studio 2008, but neither have helped.

I'm assuming that it's Dotfuscator Community edition that's causing the problem, because a colleague is using the same xml settings file on his machine, and it obfuscates the solution no problem.

My idea is that, as it says in the error message, Dotfuscator cannot find an ildasm (the library/function used to obfuscate?) file that is compatible with .NET 3.5, only .NET 2.x. Is this a correct asusmption?

Dotfuscator had been working fine, previously. But, after a recent round of Windows updates it no longer seems to work on my machine - some of the recent Windows updates have caused havok with the network and some colleagues laptops (revoking login credentials, invalidating certain programs, the usual), that's why I'm assuming it's one of the updates that has caused this.

Of course, I'm not adverse to putting it down to user error, except for the fact that the same settings file and solution outputs are not causing Dotfuscator to fail on a colleague's machine.

Any suggestions?

Answer 1

As you've guessed, this is due to Dotfuscator failing to find the proper version of ildasm for the assembly provided to it. Dotfuscator obfuscation is performed via disassembling, altering, and reassembling the assembly, so it requires versions of ilasm/ildasm that match the assembly's target version.

Dotfuscator will search in \Windows\Microsoft.NET\Framework{FrameworkVersionHere} for the proper version of ilasm and ildasm, IIRC. Do you have those executables in \Windows\Microsoft.NET\Framework\v2.0.50727? If not, you'll need to get them in there - installing .NET framework 2.0 should do so (or just copy from a colleague's computer).

Edit to reflect comments below: We found that reinstalling the Windows SDK fixed the issue, likely because the Windows SDK's registry settings had been wiped out.

Answer 2

I had to add these four lines into my dotfuscator project file to resolve the problem:

<dotfuscator version="2.3">   
   <propertylist>
      <property name="ILDASM_v2.0.50727" value="C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\ildasm.exe" />
      <property name="ILDASM_v4.0.30319" value="C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\ildasm.exe" />  
   </propertylist>

In general dotfuscator may miss any version of ildasm. It says what version is missing in error message. Just define propertiy with your specific version.

Answer 3

I wasted the guts of a day discovering that v4.9 requires SDK version 7.0 (and not 7.1 or 8.0) to 'find' ILDASM.

Still not sure if the lookup is registry-based.

TODO: Analyse what it takes to re-break it to figure out if the discovery is based on location or registry. Preemptive really could document this better and/or give more detailed errors. Have a question regarding this pending moderation on the Preemptive forum

Answer 4

The problem is the install of visual studio with integrated dotfuscator. Take dosfuscator out or reinstal visual studio without dotfuscator.

Answer 5

I had the same issue. Dotfuscator 4.9.8500 is not looking up the SDK tools for .NET 4.0 correctly - it assumes the path is found under this key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0\WinSDK-NetFx40Tools

None of the SDK installers populate this key - it seems VS2010 did (which we don't use anymore). I did not want to instrument my build for this, as we have dozens of branches with variations of the Dotfuscator config.

We're migrating to Dotfuscator 4.16.0, which doesn't have this issue (thanks to @mletterle above?), but we have to roll this out incrementally because of other knock-on effects.

My workaround for 4.9.8500: on our build agents, install the .NET 4.5.2 developer pack, then add the below to the registry, which redirects Dotfuscator to the 7.1 .NET 4.0 tools folders. Notice that the keys say "7.0" while the paths say "7.1". Backup the registry folder first!

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0\WinSDK-NetFx40Tools]
"ProductVersion"="7.1.7600.0.30514"
"ComponentName"="Windows SDK Tools for .NET Framework 4.0"
"InstallationFolder"="C:\\Program Files\\Microsoft SDKs\\Windows\\v7.1\\Bin\\NETFX 4.0 Tools\\"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0\WinSDK-NetFx40Tools-x64]
"ProductVersion"="7.1.7600.0.30514"
"ComponentName"="Windows SDK Tools for .NET Framework 4.0 (x64)"
"InstallationFolder"="C:\\Program Files\\Microsoft SDKs\\Windows\\v7.1\\Bin\\NETFX 4.0 Tools\\x64\\"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0\WinSDK-NetFx40Tools-x86]
"ProductVersion"="7.1.7600.0.30514"
"ComponentName"="Windows SDK Tools for .NET Framework 4.0"
"InstallationFolder"="C:\\Program Files\\Microsoft SDKs\\Windows\\v7.1\\Bin\\NETFX 4.0 Tools\\"