I'm using new new Microsoft.Management.Infrastructure classes to handle WMI, but I've encountered a stumbling block, and can't find any information on how to work around this using these classes without having to fall back to using System.Management.ManagementObject.
Basically, Microsoft.Management.Infrastructure doesn't expose any methods for objects, which is what I'm having difficulties with.
I've retrieved a CimClass object, let's call it Win32_Process , called the property .CimClassProperties["Handle"] to get the Handle property and .Qualifiers to retrieve a list of qualifiers for the Handle property.
At this stage I'd like to delete one of the qualifiers, but there are no methods exposed that allow such a thing.
Using Microsoft.Management.ManagementObject namespace, I could get a ManagementClass object, again Win32_Process for the sake of the argument, call .Properties["Handle"].Qualifiers.Remove(<qualifierName>) to remove the qualifier, but no idea how to do this using the new classes and there's no info out there that I can find.
EDIT: I did some digging and found that to invoke methods on CIM objects you use the CimSession class, using either CimSession.InvokeMethod or CimSession.InvokeMethodAsync methods and was able to use it to invoke a method of a CimClass and of a CimInstance, but it does not appear to be able to invoke methods of any object outside of those two, from what I can see. Is this me?
I believe, it is not possible to modify the Qualifiers. Reason is it is read only property. Also, if you want something to do in code, they take the data in list or string array and manipulate them.
This is a very late answer, but I have found myself in a similar situation with trying to change Win32_TCPIPPrinterPort Printer IP Addresses and Names, which are also ReadOnly. I did come across some articles that refer to wbemtest.exe. This utility can be used to make changes like this, but use extreme caution as it is a WMI-Object editor and can break your system. This link will explain it better https://blogs.technet.microsoft.com/heyscriptingguy/2009/08/04/hey-scripting-guy-how-do-i-use-wmi-with-windows-powershell-to-return-information-about-properties/
Related
I have a CodeFix provider, purpose of which to inject service to current class, like add new private field, parameter to constructor, assignment statement in constructor, using ServiceNamespace, and use of this field in proper place(s).
At some point, I have a name of this service, and I need to find namespace for this service to add correct using. I'm doing this via compilation.GetSymbolsWithName(typeName), but this method can return several matched symbols from different namespaces/assemblies.
So, the question: is there any way I can show this variants to user so he can decide the correct type?
For each diagnostic, you can add more than one fix.
I'm actually pursuing a way to create csv file which records could vary on type and order. They are defined by the user on both ways and I'm actually handling their types safely.
I loved using FileHelpers library in order to read/write files on C# since it's fast, reliable and trustable, so I was wondering how could I perform this export operation using it, and reviewing questions like this one the evil part comes when needing to populate the class with the desired values, so I could write the file. All the related questions are focusing on reading registries and I need to write them.
Am I right thinking that I might need to use Reflection so I could roam this new type and its properties or is there any way to "add a record" specifying the value while creating the fields?
This FileHelpers way was an option and of course the second one was doing this manually, but I was curious if there is an easier way.
var builder = new DelimitedClassBuilder("DynamicDocument", ";");
builder.AddField("Date", typeof(DateTime));
var dynamicType = builder.CreateRecordClass();
//...
Using the class builders is the best way to do this with FileHelpers. You do need to keep a copy of the type that is created so it can be used by your generic classes.
Just remember, that you must do all the work before calling CreateRecordClass() as that then generates the type.
Here is a link to another S/O question with a whole bunch of code that shows how to do it: FileHelpers.Dynamic.ClassBuilder.CreateRecordClass Error
Now, if you are working purely with properly formatted files, you can let FileHelpers do all that work for you as long as they are always properly delimited and you handle any type conversion based on the column name.
I am trying to dynamically add field properties to a record class that I am also building dynamically using FileHelpers.Dynamic.DelimitedClassBuilder. I have no issues creating the class object and I currently add a field using the AddField(String) method.
As my apps grows I now have a need to declare specific field properties in various situations. So in the same sense I wanted to use FileHelpers.Dynamic.DelimitedFieldBuilder to create a field object and then pass that to my DelimitedClassBuilder object using the method AddField(DelimitedFieldBuilder).
However I am unable to instantiate a new object using FileHelpers.Dynamic.DelimitedFieldBuilder. When I issue the following code I get an error stating that DelimitedFieldBuilder does not contain a constructor that takes two arguments.
FileHelpers.Dynamic.DelimitedFieldBuilder fb = new FileHelpers.Dynamic.DelimitedFieldBuilder("ClassName", "Type");
Looking at the documentation it appears that this class does only have properties associated with it, so I am kind of stuck on how to actually implement this. It seems like it should be fairly easy but I cant seem to figure it out. Thanks for any help.
Not familiar with that functionality of file helpers; however, in the vast majority of functions/methods across .NET there is usually a way to assign properties after the class is instantiated.
Try something like this:
FileHelpers.Dynamic.DelimitedFieldBuilder fb = new FileHelpers.Dynamic.DelimitedFieldBuilder();
fb.Whatever = "ClassName";
fb.otherwhatever = "Type";
Just a stab. I have no idea if it will work or not.
The constructors of DelimitedFieldBuilder are internal so you'll run into difficulty with your approach. However AddField(String) returns a DelimitedFieldBuilder, so you might be able to use that.
It might be easier to make your own class MyFieldBuilder which calls the standard AddField(String).
A theoretical question now.
As I understand methods are used to implement some sort of behavior and properties are used to retain some state of the object.
I found that XContainer.Nodes() as well as XElement.Attributes() are implemented as methods, not properties. And, IMHO, other methods that should be implemented as properties: XNode.ElementsAfterSelf(), XNode.ElementsBeforeSelf() XNode.NodesAfterSelf() and so forth.
So, everything that returns IEnumerable of something is implemented as method (not property) in Linq to XML.
What is the reason for that? I mean does it serve some specific case or it's just a mistake like for example String.Split() method, that returns char array instead of more expected IEnumerable<char>?
To quote Microsoft "Choosing Between Properties and Methods":
In general, methods represent actions and properties represent data. Properties are meant to be used like fields, meaning that properties should not be computationally complex or produce side effects. When it does not violate the following guidelines, consider using a property, rather than a method, because less experienced developers find properties easier to use.
Consider using a property if the member represents a logical attribute of the type.
For example, BorderStyle is a property because the style of the border is an attribute of a ListView.
Do use a property, rather than a method, if the value of the property is stored in the process memory and the property would just provide access to the value.
You can also read on "Properties vs Methods" here
I like this explanation from that last link
The operation is expensive enough that you want to communicate to the user that they should consider caching the result.
I'm trying to find a collective name for these non-"helper" classes which encapsulate method results (e.g. "SignupResult"), classes which hold multiple filter values (e.g. "ContactSearchFilter"), my SortDirection enum etc. -- I want to organize these correctly but can't find the correct name for these as a whole. Help?
Do they really have anything in common that would justify an own category name?
If you want to organize such files, I suggest putting them in the same folder/namespace as their dependencies, i.e. the enum belongs in the same namespace as the dictionary you use it with, SignupResult belongs together with the other signup process classes etc.
Depends on what you do with it. If you save it in the database, it's effectively an 'Entity'. If you just use it to pass variables around, I'd call it a 'Holder' class (though that's not really a formal term).
It's arguably interesting to consider that if you have too many of these, perhaps your design is not so great. You probably shouldn't be so-much passing results around, as doing actions based on things happening. JMHO. FWIW.
Perhaps creating a class called UserSession or something and have things like SignupResult/ContactSearchFilter as properties.