Assembly Version Madness

[Russell Stevens]

Should be trivial - I want to detect the program version so that I can
take steps to update things to the current version. Pretty simple - just use

Application.ProductVersion

So I install the app on a file server. Various workstations then load the
app and run it. Some workstations are Win98, some are XP. To enable users to
access the program, I share the folder on the server. When my customers
share a folder, the folder name on the server may be "Server Folder Name".
The default is to give the shared folder the same name, you then give the
workstation users the necessary permissions.

When you load the exe from an XP workstation, Application.ProductVersion
returns the correct version and so does Windows Explorer when you browse to
the server folder and do a File, Properties on the exe.

On a Win98 workstation, Application.ProductVersion returns version 1
regardless of what version the exe really is. So you then use Windows
Explorer on the 98 computer, browse to the exe on the server, do a File,
Properties on the exe, and there is NO version tab - Unbelievable.

Then just change the share name from "Server Folder Name" to say
"SFolder". Then when you do a File, Properties on the exe from a Win98
computer, there is now a Version tab, and Application.ProductVersion returns
the correct value.

Why would the share name of a folder totally kill the ability of Windows
explorer to display a Version tab and make Application.ProductVersion return
an incorrect value.

This can't possibly be by design (I hope). Anybody else run into this or
have any suggestions on how to make Application.ProductVersion work reliably
on a Win98 computer.

Thanks
Russ Stevens

 

[C-Services Holland b.v.]

Should be trivial - I want to detect the program version so that I can
take steps to update things to the current version. Pretty simple - just use

Application.ProductVersion

Not that I can help you, but whenever I try to call that line in my code
I get an error (null reference I think.) I've never been able to do
something like
(assuming myversion is a label on my form)

myversion.text = application.productversion

It always bombs.

Rinze van Huizen

 

[Russell Stevens]

Rinze,

Application.Product version returns a string such as

2.25.5.0 (you can specify the version in your AssemblyInfo.vb file)

If you want the major, minor version, etc. you need to parse it out.

Russ

 

[C-Services Holland b.v.]

Rinze,

Application.Product version returns a string such as

2.25.5.0 (you can specify the version in your AssemblyInfo.vb file)

If you want the major, minor version, etc. you need to parse it out.

Russ

If only I got that back Whenever I call Application.ProductVersion I
get this error:

"An unhandled exception of type 'System.NullReferenceException' occured
in System.Windows.Forms.dll

Additional information: object reference not set to an instance of an
object."

So somehow my appliction object points to nothing it seems.

Same error if I try something like Application.ProductName. Doesn't
matter if I assign it to a var, textbox or a msgbox.

Rinze van Huizen

 

[Russell Stevens]

Anyone from Microsoft hang out in this forum?

Microsoft directed me to come to this forum for this issue.

Or perhaps I misunderstood what the following means?

"A commitment to respond to your post within two business days?"

Thanks
Russ Stevens

 

[Arnaud Debaene]

Anyone from Microsoft hang out in this forum?

Microsoft directed me to come to this forum for this issue.

Or perhaps I misunderstood what the following means?

"A commitment to respond to your post within two business days?"

Newsgroups are a good source of information and halp between users,
but it is not an official support path of MS. There is no commitment
whatsoever in newsgroups, only good wolling people searching to help
one each other.

Arnaud
MVP - VC

 

[Russell Stevens]

Arnaud,

Ref:<<Newsgroups are a good source of information and halp between users,
but it is not an official support path of MS. There is no commitment
whatsoever in newsgroups, only good wolling people searching to help
one each other>>

REALLY?

Could you then explain the following direct quote from the Microsoft MSDN
subscriptions site.
*******************
"About Managed Newsgroups
MSDN managed newsgroups are available in English to MSDN Universal,
Enterprise, Professional and Operating Systems subscribers to receive free
technical support on select Microsoft technologies as well as to share ideas
with other subscribers. MSDN managed newsgroups provide:

Unlimited on-line technical support - keep your PSS incidents
A commitment to respond to your post within two business days
Over 200 newsgroups to choose from
Spam protection for your e-mail address when posting items"
******************
Are you speaking for Microsoft? or what? There was a response, but it had
nothing to do with the question at hand!

I could use a tech support incident but this problem is so blatently obvious
that a Microsoft support engineer working on another tech support incident
suggested that I come here - geesh.

If no one from Microsoft is going to review my post then someone at
Microsoft needs to revise their official stated policy.

Thanks
Russ Stevens

 

[Arnaud Debaene]

Arnaud,

Ref:<<Newsgroups are a good source of information and halp between users,
but it is not an official support path of MS. There is no commitment
whatsoever in newsgroups, only good wolling people searching to help
one each other>>

REALLY?

Could you then explain the following direct quote from the Microsoft MSDN
subscriptions site.
*******************
"About Managed Newsgroups
MSDN managed newsgroups are available in English to

<snip>
This is NOT an MSDN managed newsgroup, sorry. This is a public MS
group accessible to everybody, noy only MSDN subscribers.

Arnaud
MVP - VC

 

[Russell Stevens]

Arnaud,

You are starting to annoy me

ref <<This is NOT an MSDN managed newsgroup, sorry. This is a public MS
group accessible to everybody, noy only MSDN subscribers.>>

Please go to

http://msdn.microsoft.com/newsgroups/managed/

then in the Search For box enter "Assembly Version" and search in MSDN
Managed Newsgroups.

Voila - you will find this thread IS IN a Microsoft Managed Newsgroup.

Now perhaps I don't know how to submit my question correctly, and if you are
an MVP, then it would be appreciated it you would tell me how. But according
to Microsoft, this IS a managed newsgroup and I would sure like some help
instead of wise a** comments.

I give MS thousands of dollars every year for MSDN subscriptions - they
promise me 2 business day newsgroup replies. All I am getting is a bunch of
BULL.

Please take this up your chain until you find someone that can resolve how I
am supposed to get the promised 2 day response.

Thanks
Russell Stevens

 

[Guest]

Arnaud,

You are starting to annoy me

ref <<This is NOT an MSDN managed newsgroup, sorry. This is a public MS
group accessible to everybody, noy only MSDN subscribers.>>

Please go to

http://msdn.microsoft.com/newsgroups/managed/

then in the Search For box enter "Assembly Version" and search in MSDN
Managed Newsgroups.

Voila - you will find this thread IS IN a Microsoft Managed Newsgroup.

Now perhaps I don't know how to submit my question correctly, and if you are
an MVP, then it would be appreciated it you would tell me how. But according
to Microsoft, this IS a managed newsgroup and I would sure like some help
instead of wise a** comments.

I give MS thousands of dollars every year for MSDN subscriptions - they
promise me 2 business day newsgroup replies. All I am getting is a bunch of
BULL.

Please take this up your chain until you find someone that can resolve how I
am supposed to get the promised 2 day response.

Thanks
Russell Stevens

 

[Guest]

Try something like this:

Assembly.GetCallingAssembly().GetName().Version

[
or Assembly.GetExecutingAssembly()
or Assembly.GetAssembly(typeof(your_type_you_want_to_check)) -
to get an instance of Assembly class
]

using a Version class in conjuction with Assembly class you can easily
determine your(any) assembly version: .exe or .dll

 

[Russell Stevens]

Dariusz,

From what I can tell

Application.ProductVersion

is broke when used to determine the version of an assembly in a shared
folder that has a long share name when the app is running on a Win98 box.
Additionally, the ability to get the version from Windows Explorer is also
broke. Both of these work if the share name is changed to a short name with
no spaces.

System.Reflection.Assembly.GetExecutingAssembly().GetName.Version.ToString

works regardless of the name of the shared folder even when run on a Win98
box. I am not sure what else might be broke with the Application object -
Application.ProductName seems to work. This sure looks like a MS bug to me.

Thanks
Russell Stevens

 

[Guest]

Russell,

I am agree with you what it is a bug. I thought you are looking for
workaround for this problem, so I wrote my idea for retrieving a valid
version of assembly. I don't know if MS knows about it, maybe furums are
periodically searched by their personel for such types of bugs we writing
about. Maybe in next service pack they correct this annoying behaviour.
Summing up, I fully agree that Application.ProductVersion is not working as
anyone can expect.