microsoft.public.dotnet.framework.clr Google Group

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

Fri, 11 Nov 2009 10:59:15 UT

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

m...@nobhillsoft.com (Mia) — Tue, 11 Nov 2009 16:10:54 UT

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

itaifren...@live.com (Itai Frenkel) — Mon, 11 Nov 2009 14:32:02 UT

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

leafnode.use-...@schabi.de (Markus Schaber) — Sun, 11 Nov 2009 20:30:01 UT

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!

bvo...@newsgroup.nospam (Ben Voigt [C++ MVP]) — Fri, 10 Oct 2009 16:44:13 UT

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!

s...@no.mail (Martin Plechsmid) — Fri, 10 Oct 2009 07:23:27 UT

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

bvo...@newsgroup.nospam (Ben Voigt [C++ MVP]) — Fri, 10 Oct 2009 01:17:45 UT

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

bvo...@newsgroup.nospam (Ben Voigt [C++ MVP]) — Fri, 10 Oct 2009 01:14:40 UT

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

bvo...@newsgroup.nospam (Ben Voigt [C++ MVP]) — Fri, 10 Oct 2009 01:11:00 UT

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

s...@no.mail (Martin Plechsmid) — Wed, 10 Oct 2009 13:08:53 UT

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

jesse.houw...@newsgroup.nospam (Jesse Houwing) — Wed, 10 Oct 2009 12:29:24 UT

* 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

s...@no.mail (Martin Plechsmid) — Wed, 10 Oct 2009 11:30:30 UT

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

s...@no.mail (Martin Plechsmid) — Wed, 10 Oct 2009 09:25:02 UT

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

mail_igno...@web.de (Immo Landwerth) — Wed, 10 Oct 2009 09:17:38 UT

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

s...@no.mail (Martin Plechsmid) — Wed, 10 Oct 2009 09:08:29 UT

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.)