microsoft.public.dotnet.framework.clr Google Group

.NET Runtime 2.0 Error Reporting, Event ID 5000 - Cannot see exception details in Windows Log

2009-11-20T10:59:15Z

Probably you need to see the exception details. Check comment at [link]
This problem occurs because the default policy for unhandled exceptions has
20-kwi-08
This problem occurs because the default policy for unhandled exceptions has
changed in the .NET Framework 2.0. By default, the policy for unhandled

a brand new query tool is out on beta, we need feedback, so you get a free copy

2009-11-17T16:10:54Z

We at Nob Hill Software are working on a new query tool:
[link]
You can read all about it on the above web page, but basically, its a
very ambitious project to create what we call 'the query tool to end
all query tools': everything you ever wanted, desired, dreamed about

Looking for an event before threads exit

2009-11-16T14:32:02Z

Hello,
I'm looking for a CLR event (or hook) that allows running .NET code on that
same thread before it terminates. This hook should work for both "new
Thread()" and also threads from thread pools.
The code must run on the thread itself (and not on the Finalizer thread).
Such low level hook exists in native code (DllMain), however that code runs

Go-like duck typing interfacing

2009-11-15T20:30:01Z

Hello,
I just stumbled across the "Go" language from google. Especially, I
like the duck-typing approach to interfaces.
Now my question: Is it even possible to implement such static duck
typing using the CLR?
Managed C++ templates seem to look similary, but they work by the
compiler generating the code for the all uses, so the CLR just sees

Re: 32-bit CLR application on 64-bit system - solved!

2009-10-16T16:44:13Z

Ok, yeah, it's not that xcopy *can't* work with C++/CLI apps, it's that the
normal steps (put DLLs in the application directory) don't work. You have
to jump through hoops.

Re: 32-bit CLR application on 64-bit system - solved!

2009-10-16T07:23:27Z

Hooray!
Problem solved! The solution is in that it is not sufficient to copy
*content* of the Microsoft.VC90.DebugCRT into the application directory. It
is necessary to copy there the whole folder as a *subdirectory*.
Thanks to
[link]

Re: AppDomains and native DLLs

2009-10-16T01:17:45Z

oh gee, you already said what I did.... I was thinking of your statement in
terms of named kernel objects, but those are session-global, not
process-global.
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4512 (20091015) __________
The message was checked by ESET NOD32 Antivirus.

Re: AppDomains and native DLLs

2009-10-16T01:14:40Z

And if the DLLs import another DLL that uses global data, you'll still end
up with data sharing across app-domains no matter what you do (short of
recompiling all dependencies with /clr and app-domain awareness).
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4512 (20091015) __________

Re: 32-bit CLR application on 64-bit system - more info

2009-10-16T01:11:00Z

xcopy deployment generally doesn't work for C++/CLI apps (this is expected
to change with VS2010).
There are some tweaks to the manifest needed to get app-local CRT working.
Google is your friend.
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4512 (20091015) __________

Re: 32-bit CLR application on 64-bit system - NonDelayed screenshot

2009-10-14T13:08:53Z

It might be, though I don't think it's the problem. At first, the release
version of the application is missing MSJAVA.DLL too, and the release
version works. At second, the dependency on MSJAVA.DLL is only delay-loaded,
which means - I think - that the DLL is loaded only when necessary. My
application does not use java. At third, I have MSJAVA.DLL neither on my

Re: 32-bit CLR application on 64-bit system - NonDelayed screenshot

2009-10-14T12:29:24Z

* Martin Plechsmid wrote, On 14-10-2009 10:28:
Looks like you're missing the J# Redist package on the machine. It's a
separate download.

Re: 32-bit CLR application on 64-bit system - further info

2009-10-14T11:30:30Z

I tried the same CLR HelloWorld program on a clean installation of Windows
Server 2003 R2 SP2 Standard x64 Edition. I installed .NET 2.0 SP1 (x64
version) and VC9 redistributable packages (x86 version; release version is
installed, debug version of CRT is copied from VS2008). *Nothing* else is
installed.

Re: 32-bit CLR application on 64-bit system - more info

2009-10-14T09:25:02Z

Yes. I have copied them in the directory with the CLR executable. When they
were missing, Dependency Walker showed that.
Martin.

Re: 32-bit CLR application on 64-bit system - more info

2009-10-14T09:17:38Z

Not sure if I understood you correctly: you have those files present
and it still does not work?

Re: 32-bit CLR application on 64-bit system - more info

2009-10-14T09:08:29Z

Instead of having there Microsoft.VC90.DebugCRT.dll I have there
Microsoft.VC90.DebugCRT.manife st and the 3 related DLLs (MSVCM90D.DLL,
MSVCP90D.DLL and MSVCR90D.DLL). They are in the x86 version, and I copied
them from the <VC9.0>\VC\redist\Debug folder. (The x64 version didn't work
as the exe is 32-bit.)