NXCOMPAT and the C# compiler

re: NXCOMPAT and the C# compiler

goran.kimovski — Fri, 14 Dec 2007 11:07:20 GMT

Hey Ed,

your blog is timed as if I asked for it ;-)

I have a question around the impact of NXCOMPAT and DEP on ASP.NET applications which use interops to work with COM components, in particular when the native components are built with pre-VS2005, i.e. link o/use pre-ATL80.

My understanding is that the ASP.NET worker process is not marked with NXCOMPAT, thus even if the C# compiler outputs NX compatible assembly, when run on IIS, DEP should not prevent the ASP.NET app from running. Is this correct?

If this is not correct, i.e. the process is NXCOMPAT, my next question would be if aspnet_compiler.exe also produces NXCOMPAT assemblies when .NET 2.0 fwk SP1 is installed on the IIS machine? If that is true, is there a risk that an ASP.NET app that was running fine with .NET 2.0 fwk RTM all of a sudden starts to fail when the ASPX files get recompiled?

Thank you,

Kima

re: NXCOMPAT and the C# compiler

rbirkby — Sat, 15 Dec 2007 12:43:10 GMT

To complicate matters further, there are 2 versions of sn.exe - 32bit and 64bit. The 64bit one AFAIK isn't shipped with the NDP. It comes as part of the Windows SDK.

Community Convergence XXXVIII

Charlie Calvert's Community Blog — Wed, 02 Jan 2008 23:49:47 GMT

Welcome to the thirty-eighth Community Convergence. These posts are designed to keep you in touch with

re: NXCOMPAT and the C# compiler

Spike0xFF — Wed, 16 Jan 2008 12:02:02 GMT

Hi Ed - I just ran into this problem - or rather, a panicky user of my company's ActiveX control ran into it.

It's listed as an open issue over on the Connect site, so I pointed to your blog entry as a possible work-around.

I'm torn between absolutely admiring your work - I've worked on a few compilers - and needing to say, this NXCOMPAT thing was kind of rude. I don't mean that personally - may I explain?

Figure 10,000 developers out there, who maintain apps that use 3rd party ActiveX controls and who are working in VS. They upgrade their IDE at some point, then (possibly at a completely different time) their app gets launched on Vista. Up comes this message: "Unable to get window handle for the EZTwainX control, windowless ActiveX controls are not supported." Notice that the message names the control, and precisely describes the problem (incorrectly, but precisely.) What does the developer do? Goes off to ding the vendor of the control, because it has been clearly identified as the cause of the problem: "Hey, your control doesn't work on Vista!" The control vendor, if they still exist, scratches their head - in my case, my control has been in development and use on Vista since August. I check the code: Nope, it's always windowed. What the heck? Google, read, google, read some more - with luck and patience, find your blog entry.

Solutions:

1. Rebuild my control using VS 2005 or 2008, retest, and redistribute to app developer, who updates it in his app, retests, and redistributes his (or her) app...

2. Have developer rework their build process using your suggestions.

3. Or, as suggested by one poster - disable NX on any affected Vista machine! (it's a one-liner)

Suppose the control and application developers manage to handle each incident for 100$. Cost in the field: $1,000,000 (US). Unless you have reason to believe there are fewer than 10,000 developers babysitting apps that use ActiveX controls built with VS2003 or earlier? Personally, I'd bet the number is higher. I understand the asymmetry of the situation, just wanted to put "a bug in your ear" as my mother used to say.

re: NXCOMPAT and the C# compiler

Spike0xFF — Sat, 19 Jan 2008 01:26:37 GMT

I forgot to say what really made me mad about this NXCOMPAT thing: It's wrong! It's a bug! Writing a file with the NXCOMPAT flag, without making *any effort* to verify that the file is actually NX-compatible, is a bug. It may be politically correct, but it isn't any less of a bug than marking all exe's as '64-bit code' because "64 bits is twice as cool!" Investing effort to implement a bug, and then shipping it?? What were you thinking?

在VS 2008中使用非托管DLL以及DEP

laue — Sun, 20 Jan 2008 18:27:43 GMT

在VS 2008中使用非托管DLL的时候，可能出现内存位置访问无效的错误，文章介绍了我找寻到的解决方案

re: NXCOMPAT and the C# compiler

kadorken — Mon, 21 Jan 2008 20:59:40 GMT

We are now busy tracking down DEP errors (from within the .NET library) in OUR application (i.e. we are now testing Microsoft's code in our application) just because we now have .NET SP1 installed on our development computer. Our (just) released application was built just before .NET SP1 magically appeared on our build computer so our current customers are SAFE for now. However, I just discovered our build computer has been updated; Magically our application has now been blessed with NXCOMPAT; it will now fail (IN the MICROSOFT .NET LIBRARY NOT OUR CODE). Good thing people have started blogging about this (and we found this one) before I inadvertently (WITHOUT KNOWLEDGE) released a update to our application with potential bugs in it.

Thanks for NOT providing a compiler switch so I can add even MORE lines to our Postbuild.cmd process.

Not a happy camper.

re: NXCOMPAT and the C# compiler

behearn — Thu, 31 Jan 2008 21:25:08 GMT

This decision has a big impact for our product, too. We're about to release a new version and suddenly QA starts finding the DEP error in web pages, where there were none before. Product management is freaking out. There is no indication in the error messages or logs we can find about exactly what the problem is. So I end up googling it and find this blog. Well, I sincerely appreciate that it's documented somewhere, but...

We use many third party components in our ASP.NET and WinForms applications that we cannot recompile.

It is an extremely poor decision on Microsoft's part to have made a "breaking change" like this in a service pack that gets automatically deployed via windows update! We are upset about this because we didn't expect breaking changes in a service pack, and now have to dedicate time to deal with it. We have enough problems of our own to deal with without Microsoft making matters worse. My feedback is this: put "breaking changes" into major releases of the framework, rather than into a "mandatory" service pack.

Disappointed and wary of future service packs

re: NXCOMPAT and the C# compiler

hkabla — Thu, 21 Feb 2008 17:08:52 GMT

Hi,

I have a piece of code that compiles under MS Studio 2008 and works fine on Windows Vista. But the same .exe generates a 'execution denied' error on XP. Is there a chance that this strange behavior on XP comes from DEP? Could you help me find the way to fix this?

re: NXCOMPAT and the C# compiler

GWardell — Fri, 25 Apr 2008 01:00:55 GMT

Hi,

So far I haven't been bit by this so I think this is funny because not executing data pages has been built into Intel chips since the 80386 and on into the current Pentium chips. This was a "feature" of the old CTOS operating system when running in "protected mode".

The problem was Windows 32 bit mode didn't take advantage of it, choosing instead to use all 32bits for a memory address instead of using the segment descriptor and offset method needed for protected mode.

re: NXCOMPAT and the C# compiler

awe — Tue, 19 Aug 2008 16:01:51 GMT

I tried to run it on my exe, and it worked fine.

Then I tried to include it in the post-build event like you said:

call $(DevEnvDir)..\tools\vsvars32.bat

editbin.exe /NXCOMPAT:NO $(TargetPath)

This gave the following error when I build it:

The command "call C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\..\tools\vsvars32.bat

editbin.exe /NXCOMPAT:NO D:\Work\DotNet\RadiusStudio.NET\RadiusStudio\bin\Release\StudioVision.exe" exited with code 9009.

This is also a problem inside Visual Studio, because it is a GUI control that fails to load in the forms designer. Could this be solved by running EDITBIN.EXE on devenv.exe?

re: NXCOMPAT and the C# compiler

rajshreedugar — Fri, 19 Sep 2008 09:26:35 GMT

Hi Awe,

try the following in the post build event command line:-

call "$(DevEnvDir)..\..\VC\bin\vcvars32.bat"

call "$(DevEnvDir)..\..\VC\bin\editbin.exe" /NXCOMPAT:NO "$(TargetPath)"

This works fine for VS2005. You might want to change the location if you are using any other versions of VS. But be sure to include the path within quotes.

Cheers

Rajshree

Disable DEP on applications

Gaurav Bodar's Blog — Tue, 23 Sep 2008 03:05:41 GMT

Windows vista wont Allow ATL control on the machine. We have Data Execution Prevention to stop Executing

re: NXCOMPAT and the C# compiler

N!kky — Thu, 16 Oct 2008 19:57:28 GMT

Hi All,

I've got a similar issue. I've got a bug with by COM Interop and by using the following command in my build it get rids of the issue:

call $(DevEnvDir)..\tools\vsvars32.bat

editbin.exe /NXCOMPAT:NO $(TargetPath)

I've got it to work without signing my assemblies with a strong Name. However when we release our software we need to sign our assemblies using a .snk file. I've added the above code to my post build event however i can no longer run my app since it fails with Strong Validation Failed. What i need to do is call the above code and then sign my .exe file. How do i do this through the post build events? I'm currently using the Signing tab in visual studio 9 in my projects properties to sign my assemblies. Is there any other way to do this via the post build event?

Have seen the following command but can not get it to work because i dont know what to put for MyModule.netmodule parameter

al /out:MyAssembly.dll MyModule.netmodule /keyfile:sgKey.snk

Any ideas? Any suggestions will be help. Thanks in advance.

Regards Nik

re: NXCOMPAT and the C# compiler

ajsllc — Thu, 20 Nov 2008 19:49:24 GMT

I added this to my post-build event on a VB project.

call "$(DevEnvDir)..\..\VC\bin\vcvars32.bat"

call "$(DevEnvDir)..\..\VC\bin\editbin.exe" /NXCOMPAT:NO "$(TargetPath)"

It executes successfully, but if the "primary output" of that project is included in a deployment project, the exe that gets included in the output MSI does NOT have DEP disabled.

I have found that targetpath points to .....\projectname\\bin\x86\Release\projectname.exe

by experimentation, I have also found that if I edit bin ......\projectname\bin\x86\Release\\..\..\..\obj\x86\release\projectname.exe

that is, the obj folder instead of the bin folder

then the exe that gets included in the MSI DOES have DEP disabled.

I'm a happy camper, my problem is resolved, but I am curious as to why.

Is it that the deployment project pulls the output from the wrong folder,

or is it some timing issue about when things are copied from obj to bin?

re: NXCOMPAT and the C# compiler

ajsllc — Thu, 20 Nov 2008 20:15:26 GMT

I should have added that I am using Visual Studio 2008

re: NXCOMPAT and the C# compiler

sdasari — Wed, 10 Dec 2008 04:06:33 GMT

I am using VS 2005 and Mappoint Active X control, when i build the application on Vista i am getting the error Mappoint Failed to Load. The i have added the

call "$(DevEnvDir)..\..\VC\bin\vcvars32.bat"

call "$(DevEnvDir)..\..\VC\bin\editbin.exe" /NXCOMPAT:NO "$(TargetPath)"

and executed the application, this time Mappoint is working fine. When i deploy same project with ClickOnce deployment, i am getting Mappoint Failed to load on Vista Desktop. Please suggest me, how can i solve this problem.

re: NXCOMPAT and the C# compiler

rowter — Tue, 25 Aug 2009 21:45:27 GMT

I got a mappoint failed to load error.

What should i include in the "$(TargetPath")" . What should this be pointing to?