Does anyone know an accurate way of detecting the version of Microsoft Management Console or MMC? I need to set a install condition of having MMC v3.0 in one of my installers.
Thanks in advance.
Dong
This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
How to detect version of MMC
Started by
dxue
, Jun 10 2008 22:16
7 replies to this topic
VBScab
-
- Full Members
- 436 posts
Posted 11 June 2008 - 11:42
Use the FileSystemObject and get the EXE's file version property.
- Don't know why 'x' happened? Want to know why 'y' happened? ProcMon will tell you.
- Try using http://www.google.com before posting.
- I answer questions only via forums. Please appreciate the time I give here and don't send me personal emails.
- Try using http://www.google.com before posting.
- I answer questions only via forums. Please appreciate the time I give here and don't send me personal emails.
VBScab
-
- Full Members
- 436 posts
Posted 11 June 2008 - 14:35
| QUOTE (Zweitze @ 2008-06-11 13:28) |
| Did you try MSDN? For example http://search.msdn.m...cale=en-us&ac=8 |
That isn't really something one could realise in an MSI, without building a DLL, though, is it?
I went browsing through my script collection and came across a d/l I did from JSWare called 'File Props.VBS'. It's a VB Script class with a neat way of getting file version info from PE files.
Edited by VBScab, 11 June 2008 - 14:41.
- Don't know why 'x' happened? Want to know why 'y' happened? ProcMon will tell you.
- Try using http://www.google.com before posting.
- I answer questions only via forums. Please appreciate the time I give here and don't send me personal emails.
- Try using http://www.google.com before posting.
- I answer questions only via forums. Please appreciate the time I give here and don't send me personal emails.
dxue
-
- Full Members
- 33 posts
Posted 11 June 2008 - 18:05
Thanks VBScab and Zweitze for the quick replies.
Checking the file version of mmc.exe doesn't work as it seems no particular pattern existed across the OS that supports mmc v3.0.
I had tried staying away from writing a DLL for querying the mmc version because I hoped there would be some easier way of doing it. But looks like this is something that I have to do anyway.
Checking the file version of mmc.exe doesn't work as it seems no particular pattern existed across the OS that supports mmc v3.0.
I had tried staying away from writing a DLL for querying the mmc version because I hoped there would be some easier way of doing it. But looks like this is something that I have to do anyway.
Zweitze
-
- Full Members
- 522 posts
Posted 12 June 2008 - 09:35
| QUOTE |
| That isn't really something one could realise in an MSI, without building a DLL, though, is it? I went browsing through my script collection and came across a d/l I did from JSWare called 'File Props.VBS'. It's a VB Script class with a neat way of getting file version info from PE files. |
That would be the risky approach - ignore all official documentation by the vendor and instead pick a random file just because that's easier. Risks are:
- The selected file is not related to the prerequisite
- The selected file is installed conditionally (eg. not on 64-bit systems)
- The selected file may have a different name in future versions, or even disappear
- The selected file may be installed in different locations than anticipated
etc.
Edited by Zweitze, 12 June 2008 - 09:36.
VBScab
-
- Full Members
- 436 posts
Posted 12 June 2008 - 09:54
I'm guessing but are you by any chance a developer who creates his own packages?
My friend, I wasn't having a go at you (see the smiley?), just taking the pragmatic view of a packager, the sort who is usually under pressure to get stuff released, rather than the sort who is at liberty to spend who knows how long building - and debugging - a DLL. Don't get me wrong: I have done such things before but usually as an exercise, once the package has gone out, so that it can be used for future releases.
As for picking a random file, I couldn't really pick a more obvious candidate, could I? Do MMCs open with MMC.EXE or not?
Lastly, coming to your list:
- The selected file is not related to the prerequisite
See above.
- The selected file is installed conditionally (eg. not on 64-bit systems)
So one caters for whatever the 64-bit version is called.
- The selected file may have a different name in future versions, or even disappear
Get the name of whatever executable is associated with the MMC file extension and get that file's version.
- The selected file may be installed in different locations than anticipated
Get the EXE's AppPath from the registry.
All of the above can be done in script, which answers the last point I'd make: maintainability. How many packagers do you know with C+/C++ skills? Whereas script...any packager worthy of the title knows how that works.
EDIT:
I realise now that this discourse arises out of a misunderstanding of the question: I guess MS should refer to, say, a 'schema', just as it does with Windows Installer, rather than a 'version'.
Lastly, there may be no need to build a DLL. Have a look at DynaWrap. This allows you to make DLL function calls from any software - including script - which can access COM objects. I use it to get at non-exposed functions in MSI.DLL.
My friend, I wasn't having a go at you (see the smiley?), just taking the pragmatic view of a packager, the sort who is usually under pressure to get stuff released, rather than the sort who is at liberty to spend who knows how long building - and debugging - a DLL. Don't get me wrong: I have done such things before but usually as an exercise, once the package has gone out, so that it can be used for future releases.
As for picking a random file, I couldn't really pick a more obvious candidate, could I? Do MMCs open with MMC.EXE or not?
Lastly, coming to your list:
- The selected file is not related to the prerequisite
See above.
- The selected file is installed conditionally (eg. not on 64-bit systems)
So one caters for whatever the 64-bit version is called.
- The selected file may have a different name in future versions, or even disappear
Get the name of whatever executable is associated with the MMC file extension and get that file's version.
- The selected file may be installed in different locations than anticipated
Get the EXE's AppPath from the registry.
All of the above can be done in script, which answers the last point I'd make: maintainability. How many packagers do you know with C+/C++ skills? Whereas script...any packager worthy of the title knows how that works.
EDIT:
I realise now that this discourse arises out of a misunderstanding of the question: I guess MS should refer to, say, a 'schema', just as it does with Windows Installer, rather than a 'version'.
Lastly, there may be no need to build a DLL. Have a look at DynaWrap. This allows you to make DLL function calls from any software - including script - which can access COM objects. I use it to get at non-exposed functions in MSI.DLL.
Edited by VBScab, 12 June 2008 - 10:05.
- Don't know why 'x' happened? Want to know why 'y' happened? ProcMon will tell you.
- Try using http://www.google.com before posting.
- I answer questions only via forums. Please appreciate the time I give here and don't send me personal emails.
- Try using http://www.google.com before posting.
- I answer questions only via forums. Please appreciate the time I give here and don't send me personal emails.
Zweitze
-
- Full Members
- 522 posts
Posted 13 June 2008 - 12:10
I recall a setup designer writing an installer for software running on Windows 3.1 - it wouldn't run on Windows 3.0. So, to detect whether the OS had the right version was by checking the version of USER.EXE - a file present on all windows systems, offering functions for file access, registry access etc.etc.
Well... USER.EXE wasn't really present in all future Windows systems (in Win9x and WinNT it is replaced by USER32.DLL). And this designer didn't bother to look into official documentation that states you should use GetWinVersion() to get the OS version from 16-bit Windows.
Best of all, he was using a library that depends on VER.DLL, which was introduced in Windows 3.1.
My point is: always use the official documentation, especially if your software must be running on future versions of Operating Systems.
Well... USER.EXE wasn't really present in all future Windows systems (in Win9x and WinNT it is replaced by USER32.DLL). And this designer didn't bother to look into official documentation that states you should use GetWinVersion() to get the OS version from 16-bit Windows.
Best of all, he was using a library that depends on VER.DLL, which was introduced in Windows 3.1.
My point is: always use the official documentation, especially if your software must be running on future versions of Operating Systems.