|
Hello there! I am "successfully" using WMI to get a list of products from any computer that can be accessed remotely. I understand that it only shows products that were installed using a MSI file.
What I would like is to list products installed (MSI, EXE, or whatever... not just MSI). Another thing I had to ask was if there was a better way to doing this? You might suggest reading the registry, but the problem is the computers that this application will run on is x86 and the servers are x64. So you can't read a x64 registry from a x86.
Does anyone have a better solution that will increase the speed and also show ALL products? I have read there really isn't a way to speed up WMI when getting a list of products.. just the way it is designed.
In case you want to see code:
public List<Product> InstalledApplications(string dns)
{
List<Product> products = new List<Product>();
try
{
ManagementScope scope = new ManagementScope(@"\\" + dns + @"\root\CIMV2", conn);
ManagementObjectSearcher mos = new ManagementObjectSearcher(scope, new ObjectQuery("SELECT Name, Vendor, InstallLocation, InstallDate2, Version FROM Win32_Product"));
foreach (ManagementObject mo in mos.Get())
{
if (mo["Name"] != null)
{
Product product = new Product();
product.Name = mo["Name"].ToString().Trim();
if (mo["Vendor"] != null)
product.Vendor = mo["Vendor"].ToString().Trim();
if (mo["InstallLocation"] != null)
product.InstallLocation = mo["InstallLocation"].ToString().Trim();
if (mo["InstallDate2"] != null)
product.InstallDate2 = ParseCIMDateTime(mo["InstallDate2"].ToString());
if (mo["Version"] != null)
product.Version = mo["Version"].ToString().Trim();
products.Add(product);
}
}
}
catch (ThreadAbortException) { }
catch (Exception ex) {
EventLog.WriteEntry("ADEM Application", ex.Message, EventLogEntryType.Error);
Product product = new Product();
product.Name = "Error";
product.Vendor = ex.Source;
product.InstallLocation = ex.ToString();
products.Add(product);
}
return products;
}
|
|
|
|
|
I don't
|
|
|
|
|
Jacob Dixon wrote: I understand that it only shows products that were installed using a MSI file.
It only shows those applications that have registered an "uninstaller" with Windows. Those applications can be found in the "Add/Remove applications" applet from your configuration panel.
Lots of older products don't register their uninstaller, or don't have one. Windows has no way of knowing that there's a new application on my computer if I plugin my USB-stick and launch FireFox-Portable.
Jacob Dixon wrote: Another thing I had to ask was if there was a better way to doing this? You might suggest reading the registry, but the problem is the computers that this application will run on is x86 and the servers are x64. So you can't read a x64 registry from a x86.
How about reading it on the system itself, and sending a XML-file with the results once your server requests a list of all installed apps?
I are Troll
|
|
|
|
|
Ahhh
So are you suggesting that I use WMI to create a process that reads it own registry key and sends me back the information?
|
|
|
|
|
Jacob Dixon wrote: So are you suggesting that I use WMI to create a process that reads it own registry key and sends me back the information?
Doesn't have to be WMI, you could also read the registry directly;
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall
If the application has an uninstaller, there will be an entry called "UninstallString", sometimes even an "QuitUninstallString".
..but yes, I was suggesting to create a local proces that does it's job (when the computer boots, or at the request of the server) and that sends the information. It would divide the task into two smaller subtasks; reading the information on a PC, and sending it to a server.
I are Troll
|
|
|
|
|
Uhm... but this was the first solution I tried before WMI. When reading the registry from a remote computer you will only get the applications that are the same processor type. Meaning you can only read x86 keys if you are on a x86 system. So a Windows XP x86 cannot read all the programs that were installed as x64.
Please correct me if I am wrong
|
|
|
|
|
Jacob Dixon wrote: When reading the registry from a remote computer
I was suggesting to read the registry (or use WMI) from the client-computer, using a small console application for example. Write the results to a file, and send it to the server
I are Troll
|
|
|
|
|
You can try using remote registry access instead of WMI. It should be faster.
You will have to allow remote access to the registry keys you want to read.
Have a look here[^] for some examples.
Good luck.
2+2=5 for very large amounts of 2
(always loved that one hehe!)
|
|
|
|
|
Yeah I don't think that is going to work. Because lets say I'm on a Windows XP x86 machine and I'm trying to read a Server 2008 x64 registry values. I will only have access to the WOW6432 node and nothing else. So what I will get back is only applications that were installed as x86 not x64 (a x86 can't read a x64 registry I believe, so I won't get ALL of the installed applications)
|
|
|
|
|
You can locally read the x64 part of the registry hive from 32 bit processes though (with the flag KEY_WOW64_64KEY ) - doesn't that work for remote access? (I have no idea myself)
|
|
|
|
|
Locally yes... but when you are trying to access it from a remote computer with a different bit it will default to the wow6432 node. I haven't tried going from a x64 to a x86 but I know for sure that going from a x86 to a x64 will default to the Wow6432 and there is no way of reading elsewhere.
Only real way is to execute it on the local computer for reading registry
|
|
|
|
|
Stuart Celarier[^] and I continue the set of screencasts on Channel 9[^] about new language features in C#. It's a Whirlwind Tour of the important language features of C# 4. Stuart describes each major feature and why it is useful. But he doesn't get into best practices nor suggested usages. Just the facts about each feature.
Whirlwinds are bite-sized webcasts, generally shorter than 15 minutes. You can start anywhere in the series to learn about the parts you're most interested in.
What's new in C# 4
- Whirlwind 9 - Introducing C# 4[^]. This session reviews the history of C# and provides an overview of the features in the upcoming screencasts.
- Whirlwind 10 - Dynamic Lookup[^]. This session on dynamic lookup introduces a new pseudo-type dynamic into the C# type system. It's used to call dynamic languages, COM object, or XML using types that are not known at compile time (aka duck typing). Stuart introduces the concepts of dynamic lookup and how you use it in your C# code.
- Whirlwind 11 - Named & Optional Parameters[^]. Stuart describes the feature that VB programmers have known, using parameters by name and having default values set on parameters that are not specified.
Three more coming later this week.
- Whirlwind 12 - More COM Love. Stuart describes the importance of these two new features in C# for COM Interop.
ref keyword is optional if you are not going to use a return value when calling COM.
No Primary Interop Assembly (PIA) is required. - Whirlwind 13 - Covariance & Contravariance. These features provide way for you to access collections of derived classes and base classes.
- Whirlwind 14 – Events. Stuart shows how the compiler handles eventing. The compiler no longer sets locks on events, instead uses a compare and swap technique. Stuart compares C# from .NET 3.5 and .NET 4 to show the differences and explains the implications for your existing code.
|
|
|
|
|
Although this is interesting information, I don't think this is the place for it. The forums are for asking questions, advice, etc, not for advertising and self-promotion.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
The self promotion is in slightly bad taste but hey this is a dotnet centric site after all.
Listened to the first few minutes the C# 4, man you guys really swallowed the saccharine, I wonder if that format really goes over well in the US, I walked out, I'll read about it somewhere else rather than put up with that condescending crap.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I'm writing some code that does a lot of bit/byte handling and I want it to be maintainable without the overhead of calling functions.
Is there any equivalent to C++ macros?
Thanks.
|
|
|
|
|
There isn't an equivalent to macros in .net that I'm aware off.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
I think you're right, I was asking just in case I'd missed the obvious.
|
|
|
|
|
I wouldn't worry about function overhead too much, if they're small and contain only simple control flow logic they get inlined automatically by the JIT compiler - so most typical macro's should be inlined
(only when no debugger is attached, though)
|
|
|
|
|
Thanks, they're even simpler than that so it should work fine.
|
|
|
|
|
There are some funny restrictions so I guess I should list them.. for completeness and all
Methods are not inlined if (but not only if):
- it takes an argument which is a struct (build-in ValuesTypes such as Int32 do not count)
- it contains any exceptions handling (throwing is OK though)
- it is virtual (even if sealed - future versions may fix)
- it contains control flow less simple than a single if/else (for/while/do/switch/multiple if's)
- it is bigger than 32 bytes of IL
- random other reasons or a MethodImpl(MethodImplOptions.NoInlining) attribute
Methods are inlined whenever the JIT compiler feels like it and it wouldn't break any of the above rules
All non-static methods in a struct take a struct as implied first argument (this ) and are therefore not considered for inlining (worst restriction, IMO).
Short-circuiting operators and ?: count towards the limit of 1 if .
Method calls are OK
|
|
|
|
|
It will be simple static functions, mostly reading bytes from an array into 12/16/40 bit values so should be fine.
|
|
|
|
|
If you wait a moment you'll get a reply from PIEBALDconsult telling you there is nothing stopping you from using the C/C++ preprocessor as a build step for C# apps.
|
|
|
|
|
Never, ever ask about dates whilst he's online - everyone, even end users, should be forced to use ISO 8601 apparently
DaveIf this helped, please vote & accept answer!
Binging is like googling, it just feels dirtier. (Pete O'Hanlon)
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)
|
|
|
|
|
You bet. Well, not forced, per se...
|
|
|
|
|
DaveIf this helped, please vote & accept answer!
Binging is like googling, it just feels dirtier. (Pete O'Hanlon)
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)
|
|
|
|