How can I handle the ManagementObject Class in .Net 6.0? - .net-6.0

I'm with Microsoft Visual Studio Community 2022 (64-bit) Version 17.0.2, .Net 6.0, and I'm unable to work with the ManagementObject.
Here is the fragment of code I'm testing:
using System;
using System.Management;
public class Sample
{
public static void Main()
{
ManagementObject o = new ManagementObject();
o.Path = new ManagementPath("Win32_Process.Name='calc.exe'");
}
}
However, when I try to run the second statement, that is to say what is the object I want to work with (in this example 'calc.exe'), I get the error
System.NullReferenceException: 'Object reference not set to an instance of an object.'
I'm using System.Management.dll found in the GAC and in c:\Windows\Microsoft.NET\Framework64\v4.0.30319.
I fear that there is mismach of versions, but I'm unable to find the correct version.
Or perhaps that object has been discontinued in .Net 6.0.
Please tell me.
Thanks

Related

.NET Framework 4.8 seems to use C# version older than 7

It seems like I have got problems with vs not handing inline var declarations.
It turns out that is uses an old version of c#.
Here comes a screenshot that shows that out string link is not compiling.
I add the source without screenshot as well
if (foo(appid, webuid, out string link))
{
result.Body += link;
}
The function I am calling has the signature
public static bool foo(string appid, string baz, out string link)
{
/* code */
}
Why is an older C# version used by vs?
In my project, I have selected .NET Framework 4.8 as target.
The error message reads
Error CS8059 Feature 'out variable declaration' is not available in C#
6. Please use language version 7.0 or greater.
I used a comment to formulate the answer. I checked the csproj file and searched for LangVersion.
<LangVersion>6</LangVersion>
Removing the line solved the problem.
The language version nowadays is based on the .NET framework version and is not separately specified.
You cannot set the language version in the projects advanced properties, but the setting seems to be respected despite that.

Visual Studio throws SEHException when debugging IOT Core on fresh installation

I have created a nearly blank Windows IOT Core background task and if I include a method that use the "double" data type it will throw an SEHException if I step-over it after hitting a breakpoint. I have seen these weird things before when the versions of IOT Core installed on the PC vs. Raspberry PI don't match, but as far as I can tell I have things matching. Any ideas?
I have tried:
Changing the target min/max version in the VS Project.
Updated to the latest Universal Windows nuget packages
Ensured that the OS version on the PI (10.0.17763.107) matches the UAP version show in visual studio (though is says 10.0.17763.0), I can't find any way to change that
Even downloaded newest version of VS 2019, same thing
Simple code (do not step-into the method, if you do that it works):
public sealed class StartupTask : IBackgroundTask
{
public void Run(IBackgroundTaskInstance taskInstance)
{
double x = DoNothing();
Debug.WriteLine(x);
}
public double DoNothing()
{
return 300.7D;
}
}
Exception I get when step-over:
https://imgur.com/osiJngg

ShimNotImplementedException after upgrading Visual Studio 2013 and Microsoft Fakes v12

We are utilizing Microsoft Fakes with Visual Studio 2013. After updating to Visual Studio 2013 Update-4 or Update-5, we are getting ShimNotImplementedException's in our tests.
We have followed instructions found in other SOF questions and turned off the SpecificVersion of our Microsoft.QualityTools.Testing.Fakes references. This allows a compile but the tests still fail when run.
The hint we needed to solve this was found in MSDN forums.
The underlying issue is that the legacy tests did not define specific methods
on the ShimXXX object that the code based is using. Under version 11
all is well; version 12 is a different matter.
The stack trace for the ShimNotImplementedException gave the needed information on the missing property/method:
Microsoft.QualityTools.Testing.Fakes.Shims.ShimNotImplementedException
at $Func`2NotImplementedf5b9281e-32b0-4bf3-9079-6a54470670de.Invoke(SiteContext arg1)
at Sitecore.Sites.SiteContext.get_Database() //THIS IS THE PROBLEM PROPERTY
at Sitecore.Ecommerce.ShopContext..ctor(SiteContext innerSite)
at ActiveCommerce.UnitTest.ProductStockManagerTests.get_MockShopContext()
at ActiveCommerce.UnitTest.ProductStockManagerTests.GetAvailability_AlwaysInStock()
Adding the missing property to our shim construction solved the issue:
return new Sitecore.Ecommerce.ShopContext(new ShimSiteContext
{
PropertiesGet = () => new NameValueCollection(),
DatabaseGet = () => null //ADDING THIS SOLVED THE ISSUE
});
I ran in to a similar problem after upgrading several of our projects from .NET 4 to .NET 4.5.2 using Visual Studio 2015. All the sudden several previously passing tests started failing. The common denominator was that all of the tests were using Shims to mock registry access.
What appears to have happened is that something changed in the handling of the Dispose method. Originally I had not implemented a Dispose method on the RegistryKey shims. That didn't seem to cause any trouble running under .NET 4. However after the switch to 4.5.2, it is implicitly being called all the time.
The solution was simple: I just added a stub for Dispose.
Microsoft.Win32.Fakes.ShimRegistryKey.AllInstances.Dispose = (key) => { };
The tests now pass again.
Note that setting it to NULL did not solve it for it. There has to be a method.

Visual Studio 2010 doesn't find the [DllImport("")]

I'm trying to use an C++ library in my c# application but my Visual Studio 2010 doesn't know the [DllImport("")]-method at all. He always ask me to generate the Methodstub for DllImport.
I already added the "using System.Runtime.InteropServices;" but it doesn't work.
Thanks for your helpt!
It sounds like you're using the DLLImport in the wrong spot in your code. You didn't post your code, but make sure its not in a method. Try putting it in your class:
public class MyClass
{
[DllImport("")]
//method
public Class()
{
}
// Other methods
}

Adventures on Enterprise Library 5.0: Who moved my cheese (namespace)

Jesus, Krishna, Budda!
I've migrated to EntLib 5.0, but classes like ISymmetricCryptoProvider are not recognized anymore. Funny to say that Data, Logging and other blocks are working compiling fine.
Here's the problematic class:
using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.Practices.EnterpriseLibrary.Common.Configuration;//-->it's not working anymore
using Microsoft.Practices.EnterpriseLibrary.Security.Cryptography;//-->it's not working anymore
namespace MyClassLibrary.Security.EnterpriseLibrary
{
public sealed class Crypto
{
public static ISymmetricCryptoProvider MyProvider
{
get
{
//IConfigurationSource is not recognized either, neither SystemConfigurationSource
IConfigurationSource cs = new SystemConfigurationSource();
SymmetricCryptoProviderFactory scpf = new SymmetricCryptoProviderFactory(cs);
ISymmetricCryptoProvider p = scpf.CreateDefault();
return p;
}
}
The references are fine on project too. I really don't know why this particular project it's causing too many trouble on VS2010! Older references were deleted, project was cleaned, rebuilt, but can't make it compile :-(
The references are:
Microsoft.Practices.EnterpriseLibrary.Common
Microsoft.Practices.EnterpriseLibrary.Logging
Microsoft.Practices.EnterpriseLibrary.Logging.Database
Microsoft.Practices.EnterpriseLibrary.Security
Microsoft.Practices.EnterpriseLibrary.Security.Cryptography
Why some namespaces can be found while others can't?
Based on the 4.1 references that you have, you are still referencing the Enterprise Library 4.1 assemblies. You need to remove those references and add references to the Enterprise Library 5.0 assemblies.
The cryptography block should be usable as is without changing your code. Also make sure to update the "references" in all of your configuration files.
Share the command-line when building (output window, csc.exe command line with all the -r's to see what references are going to the compiler)? It might suggest the problem.

Resources