By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,562 Members | 1,318 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,562 IT Pros & Developers. It's quick & easy.

managed C++ and the Application class

P: n/a
Hello!

I have a problem with managed C++ and the Application class

I want to use Application::CommonAppDataPath but the only answer I get
is "D:\Documents and Settings\All Users\Application Data\\\1.0.0.0"

I have tried changed the items (alredy present) in assemblyinfo.cpp
but that doesn't have any effect.

I can't figure out what I am doing wrong.
Are there other propeties that need to be changed/added to make this
work?

Any help would be appreciated...

Greetings: Mårten
Nov 17 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
> I have a problem with managed C++ and the Application class

I want to use Application::CommonAppDataPath but the only answer I get
is "D:\Documents and Settings\All Users\Application Data\\\1.0.0.0"

I have tried changed the items (alredy present) in assemblyinfo.cpp
but that doesn't have any effect.

I can't figure out what I am doing wrong.
Are there other propeties that need to be changed/added to make this
work?

Any help would be appreciated...


I'm assuming you're worried because it always pops up "1.0.0.0" even if you
change the assembly version, right? If so, it might be useful to know that
this path is not based on the assembly version but on the "Product Version",
which is changed through the not-very-intuitively-named
AssemblyInformationalVersionAttribute attribute.

--
Tomas Restrepo
to****@mvps.org
Nov 17 '05 #2

P: n/a
Tomas Restrepo (MVP) wrote:
I'm assuming you're worried because it always pops up "1.0.0.0" even
if you change the assembly version, right? If so, it might be useful
to know that this path is not based on the assembly version but on
the "Product Version", which is changed through the
not-very-intuitively-named AssemblyInformationalVersionAttribute
attribute.


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?

Mårten
Nov 17 '05 #3

P: n/a
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
Nov 17 '05 #4

P: n/a
Ok Thanks so much for the help, now I at least know what's happening.
I was started to feel really stupid for not getting this to work (and I
couldn't find any info about it anywhere) :-)

///Mårten

Nov 17 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.