Marten,
Ah, thats good to know but I'm wooried about the whole string becuase
there should be other stuff there too between "D:\Documents and
Settings\All Users\Application Data\" and "\1.0.0.0" like "D:\Documents
and Settings\All Users\Application Data\stuff\morestuff\1.0.0.0" and I
can't get that to work either.
Are there more attributes that need to be added for this?
Humm... that just doesn't work in MC++ from what I've seen.
The problem is that for MC++ assemblies (unless you do some really weird
things) there's not an "Entry Type" in the sense there is for C# or VB.NET.
By Entry Type I mean a class where the Main() method is defined, but rather
the entry point is a global function.
The problem is that the rest of the stuff that's missing in there is
acquired in the Application class from the attributes in the assembly.
However, it goes around it in an ugly way:
Instead of simply finding out what assembly started the process and looking
at the custom attributes defined in it, it does something like this:
- Find the assembly that started the process
- Ask the assembly for the entry type
- Ask the entry type for the assembly it is defined in
- Ask that latter reference for the attributes.
Of course, in MC++ everything goes down the drain in the second step,
because that entry type will be null, so no way to ask for the rest of the
attributes.
A huge bug in the System::Windows::Forms assembly, if you ask me.
For the curious, this can be seen in the code for the get_ProductName method
of the System::Windows::Forms::Application class.
Ronald, or anyone... can this be at least reported? It sounds like however
wrote the class made a bad assumption as to how a .NET process get started
:(
--
Tomas Restrepo
to****@mvps.org