SlimDX installs ngen-ed assemblies with the /profile switch

[GoogleCodeExporter]

SlimDX appears to install ngen-ed assemblies with the /profile switch. Normally 
this would not be a problem, however it seems to cause issues with certain 
performance profilers.

The following MSDN thread details the issue, as seen in PEX, but I experienced 
exactly the same thing using Red Gate's ANTS profiler.

http://social.msdn.microsoft.com/Forums/sr/pex/thread/c347ddbf-4c08-4612-a127-c9
2e87f2572d

In particular, the behaviour seen using ANTS Performance Profiler is that 
profiling any Windows Forms application with crash instantly while attempting 
to access the System.Windows.Forms.SR class. There does not appear to be any 
obvious reason as to why SlimDX should affect this assembly, but we've 
confirmed that the profile ngen images are absolutely the cause.

It appears that the actual underlying issue is related to how profilers have to 
attach themselves to assemblies. While ideally profile images should not cause 
profiling to crash, Red Gate inform me that there is no alternative methodology 
for attaching profilers, so the only thing that can be done is for assemblies 
to avoid using the feature. In actual fact, it appears that SlimDX is the only 
assembly on my system that uses ngen with the /profile switch - removing these 
assemblies does not break SlimDX and allows profiling to succeed again.

As per the MSDN thread, the workaround is to run

ngen.exe uninstall * /profile

from both the 32-bit and 64-bit Visual Studio Command Prompts, but the ideal 
solution would be for SlimDX not to install these ngen images in the first 
place.

Original issue reported on code.google.com by daniel.s...@gmail.com on 21 Aug 2012 at 9:19

[GoogleCodeExporter]

Our installers have been ngen-ing for a long time as a performance benefit. If 
you absolutely don't want it ngen-ed, I'd suggest creating your own custom 
installer. It's not difficult, and our documentation has some limited 
information on the subject.

Original comment by Mike.Popoloski on 10 Sep 2012 at 2:09

• Changed state: WontFix

[GoogleCodeExporter]

Thanks for the comments Mike - however I think I wasn't clear enough in my 
original report.

The issue is not having ngen-ed assemblies - that's absolutely fine. The issue 
is that SlimDX in addition generates ngen assemblies for profiling (ngen.exe 
/profile) - it's these that cause the issue. These files are not necessary for 
day-to-day operation and as best as I can tell, no other assemblies on any 
system that I have checked actively use the /profile flag (possibly because it 
causes these issues).

So the resolution to this is to definitely keep using ngen, just to drop the 
/profile switch!

Original comment by daniel.s...@gmail.com on 10 Sep 2012 at 9:08

[GoogleCodeExporter]

Or in fact, looking at the install scripts, simply dropping the extra profile 
image from being installed:

e.g.

SlimDX.wxs:

<netfx:NativeImage Id="SlimDX_NGEN_x64_net20" Priority="1" Platform="64bit" />
<netfx:NativeImage Id="SlimDX_NGEN_x64_net20_debug" Priority="2" 
Platform="64bit" Debug="yes" />
<netfx:NativeImage Id="SlimDX_NGEN_x64_net20_profile" Priority="2" 
Platform="64bit" Profile="yes" />

It's the last line here that's a problem, not the first two.

There are a couple of places in this script that install profile images, all of 
which should be removed - which can be done without affecting users at all, as 
these images are only used by profilers, not in day-to-day running or 
development (and actually they apparently don't even work in profilers!)

Original comment by daniel.s...@gmail.com on 10 Sep 2012 at 9:35

[GoogleCodeExporter]

Ah, I see. I wasn't aware there was a separate set of ngen images for profiling 
apps. That's more reasonable.

Original comment by Mike.Popoloski on 10 Sep 2012 at 4:52

• Changed state: Accepted

[GoogleCodeExporter]

Not a problem! Thanks for sorting this out Mike.

Original comment by daniel.s...@gmail.com on 10 Sep 2012 at 5:41