Category: .NET

20 May

Moon# is online!

Moon# has its own website on GitHub : https://github.com/xanathar/moonsharp

Also, if you want to peek at the current backlog: https://www.pivotaltracker.com/s/projects/1082626

 

BTW, I’m moving all my open source efforts – however weak they might be – from various sources (mainly, here or google code) to GitHub, to have everything in one place.

 

[This post has been edited, as originally the project was hosted on CodePlex]

22 Nov

Porting .NET app to Vista.. DEP strikes!

STOP

An interesting issue happened these days when I tried to port some apps to Vista.

Basically all .NET apps compiled with Visual Studio 2005/2008 are marked “NX compatible” by default. If your .NET app uses an incompatible DLL or COM object, the app will crash. What I found funny was that the message was a standard access violation error instead of a more specific DEP error.

Debugging it was not easy: I was unable to step through the code in VS2005 and using WinDbg wasn’t much of help too, except that the line where it crashed was something like a mov [esp+24h], constant with ESP well within limits — an instruction which should not generate an access violation exception given the current ESP value.  At that point I was starting to think that my “attempt to read or write protected memory was, in fact, something else.

Luckily my mind went to DEP and in less than 1 minute of Google search I was able to find this link with a good solution which, for the lazy and to preserve history is to add the following two lines as a post-build step.

call “$(DevEnvDir)..\tools\vsvars32.bat”
editbin.exe /NXCOMPAT:NO $(TargetPath)

I tried, without much faith, and it worked. And the C# app was finally working on Vista. And while you are fuddling with post-builds, go on and enable LARGEADDRESSAWARE while you are at it. 32bit users will thank you.

21 Nov

TargetInvocationException in asynchronous web service call

I’ve seen so many solutions around to solve a TargetInvocationException raised by an asynchronous web service call in .NET and they are all but satisfactory. Some go so far to create a worker thread which is overkill and, above all, a clear sign of cargo culting.

The solution is very very simple. The exception is raised if a call fails due to a network problem, and you have accessed the Result properties of the completion event arguments. Simply check if the Error property is null before accessing the Result property (it’s this access which raises the exception).

Filed under: .NET, Programming