I've read here that Microsoft is deprecating WMI. I need to start a project in .NET Core and query information from Windows, e.g. Win32_OperatingSystem or Win32_LogicalDisk.
I'v read that you should avoid Get-WmiObject in PowerShell and use Get-CimInstance instead. What (which Nuget/library) should be used in .Net Core now to query those kind of information?
You can use the Windows Compatibility Pack (article, nuget) for .NET Core which gives you access to a lot of Windows-only APIs but restricts your app to running only on Windows, probably not something you're worried about. This compatibility pack is also known as platform extensions. With this you would need to learn how to use the classes in the System.Management namespace (API Ref, example code 1, example code 2). Keep exploring the API for examples.
Additionally, it looks like there is a newer cross-platform open-source system similar to CIM made by Microsoft. Though apparently not everything available in WMI is available with this, so your mileage will vary: https://www.nuget.org/packages/Microsoft.Management/ and https://www.nuget.org/packages/Microsoft.Management.Infrastructure/
Hope this helps.
Related
I need to find the product version of an installed application using the product code GUID. Is there a way to do this using a simple API call of some sort? I have found ways to do it using P/Invoke and the WindowsInstaller namespace, but I am trying to avoid using P/Invoke.
The Windows Installer exposes Win32 API functions (P/Invoke) as you have discovered. It also has COM automation interfaces that wrap these APIs but I'm sure you can guess is this is even less elegant. Windows Installer XML (WiX) Deployment Tools Foundation (DTF) has an MSI interop library that wraps it as managed code but I'm sure you can guess what it's doing under the covers: P/Invoke.
There are ways of getting it from the registry but this is not the official API and is less elegant IMO.
So to answer your question, you are already doing it in a very good and professional way.
If you want to get sneaky you can look through the registry to figure it out. When an MSI is installed windows creates a set of registry keys under:
HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\<munged-ProductCode>
or
HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\<munged-ProductCode>
(depending on your machine/MSI bitness)
Under that registry location there should be a registry value named "ProductVersion". The trick is to know how to 'munge' a windows GUID (see http://www.vmwareinfo.com/2011/09/surgically-eliminating-windows.html).
I am trying to write my own CSP. I am trying to do this by implementing a dll file, but I am not sure if I am on right way.
I found something like this:
Cryptographic Service Provider Developer's Toolkit (CSPDK)
there are samples with CSP API
CPAcquireContext
CPGenKey
... etc.
(it looks for me like an old api or api for winCE)
And here comes my question, which functions should I implement to provide new CSP for windows 7 and XP.
Is my plan good? - should I implement simple DLL and put her reference in register?
Or am i missing something?
You might be missing CNG which is a (long term) replacement for the MS Crypto API. You can create modules for that as well. Unfortunately it is only available since Vista. Windows XP is too old (and you should probably not be producing new applications for XP anyway).
Your HSM vendor will have their CSP written for you. You will get this csp when you install their driver. All you will be required is to access this CSP from your code.
To interface with your HSM vendor's CSP(check what they support), either you should use PKCS#11 or use the cryptoAPI CSP functions.
I need to work with some bitmaps in managed code and save them as PNG files. Should I use Microsoft.WindowsAPICodePack.DirectX.WindowsImagingComponent, or System.Windows.Media.Imaging? They both seem very similar, and I'm not sure why I would choose one over the other. Can anybody compare and contrast them?
They both use WIC, that's why they are so similar. The Windows API Code pack is retired content, you'll want to use the WPF namespace since it is available on .NET 3 and up and doesn't require a separate install.
Microsoft.WindowsAPICodePack.DirectX.WindowsImagingComponent is in the Windows API Code Pack, which is a source code library that you would need to build into your application. On the other hand, System.Windows.Media.Imaging is included in the .NET Framework.
If you have no other use for the Windows API Code Pack, I would recommend using System.Windows.Media.Imaging. I believe the inclusion of a WIC API in the Windows API Code Pack is primarily for interoperability with the DirectX APIs in the Code Pack, which have no equivalents in the .NET Framework.
Our VB6 application uses a 3rd party control (PowerTCP from Dart) for SSL3 connectivity. However, this doesn't seem to work on Windows 7 - and I have not found any useful information on what I can do to make it work.
Is there a VB6.0 compatible control that will work on Win 7 for SSL3 communication?
Unfortunately, I can only suggest a workaround, not a solution: If you do not find a suitable ActiveX control for your VB6 application, you might consider migrating the communication part of your application to VB.NET.
This has the following advantages:
Calling .net code from VB6 is not hard.
The .net Framework has a built-in SSLStream class, which might already do what you want, so you're not dependent on a third-party component.
Since VB6 IDE support ended in April 2008, you will probably want to migrate your application to VB.NET sooner or later anyway. Therefore, migrating parts of your application now might be a better investment of your time than familiarizing yourself with a new third-party ActiveX control.
It has the following disadvantages:
One more layer in your application: Your VB6 code can call the .net code, but not vice-versa.
You need to familiarize yourself with the .net-COM interop stuff (it's not difficult, but it's something that needs to be done).
Your deployment process becomes more complicated, since you require the .net Framework to be installed on your customer's machines and you need to register your .net library as a COM component (so that your VB6 application can access it).
Dart still support the ActiveX control - why not ask them for help directly and post a question on their support forum?
Apologies in advance if you've already tried this.
I wanted to know what i shouldn't do in code that will prevent my C# app from running on mac.
In general you shouldn't use anything from the Microsoft.* namespaces, no PInvoke (DllImport in C#) and UI might be problematic as well.
Further information on Mono compatibility is contained in the Mono Guide Porting Winforms Applications. Existing applications can be checked for compatibility using the Migration Analyzer tool.
UPDATE: PInvoke actually works in Mono, but if you want to have it working cross-platform you must provide a native shared library with the same interface for each platform (i.e. Win API most likely will not work).
Mono's Application Portability guide is a good reference.
In addition to divo's recommendations, I would recommend the Mono Migration Analyzer (MoMA) tool: "The Mono Migration Analyzer (MoMA) tool helps you identify issues you may have when porting your .Net application to Mono"
Also, I would keep an eye on Miguel de Icaza's blog, and the Mono Project website.
In his presentation for the Boston.NET Users Group this month, he showed a preview of a Visual Studio plugin that launches your app on Mono using a VM! This lets you test compatibility during the development process.
I believe their goal was to release it at TechEd 2009, so look for an update over the next month or so.
You will, at the very least, want to try and avoid using Windows Forms, since that is just a paper-thin layer on top of the Windows native UI.
Mono emulates it somewhat with help from WINE, but I wouldn't trust that.
Mono did this a while ago but the effort was abandoned. See WinForms on Mono for more information. Thanks jpobst.
Try using GTK# or Qt# (although I'm not too sure the latter one actually exists) for cross platform support. You might also consider using Java with SWT or even Swing instead of C#, but that will probably not be an option you're willing to consider.
Using anything related to P/Invoke is probably also a bad idea, since that invokes native code which will probably not be portable (unless you write it yourself, then you can choose to make it portable).
I'm not sure if it is possible with mono, but WIN32 API calls will definitly not work ;)