mscorlib.dll is always automatically referenced by the build system - .net-4.0

I tried to create a class library in .NetFrameWork 4.0.
I used the below code in a class and trying to add mscorlib.dll from .NetFrameWork 4.0 since the System.Type is residing on mscorlib.dll.
string str3 = (string)type.Format(str2, obj1, obj.properties.email.value);
But while adding the reference ,there is an error occured
Anyone please help me in this

You don't need to add reference to mscorlib.dll as it is automatically refered by the build system.
For using "Type" class,all you need to do is,just use the "using System" namespace.
Check this:

Related

Hangfire looking for ISet in mscorlib.dll

I'm getting this runtime exception with Hangfire after upgrading to .NET6
System.TypeLoadException: Could not load type 'System.Collections.Generic.ISet`1' from assembly 'mscorlib, Version=4.0.0.0
at Hangfire.Common.TypeHelper.TypeResolver(Assembly assembly, String typeName, Boolean ignoreCase)
at Hangfire.Common.TypeHelper.DefaultTypeResolver(String typeName)
at System.Linq.Enumerable.SelectArrayIterator`2.ToArray()
at Hangfire.Storage.InvocationData.DeserializeJob()
ISet isn't in mscorlib.dll from what I can tell. It's supposed to be in System.Runtime.dll according to the docs.
Any ideas why Hangfire is doing this? I'm using Hangfire.AspNetCore 1.7.27.
As said in the comments, you should look in your Hangfire database for a serialized parameter featuring a ISet.
It is the deserialization of this parameter which causes the issue, as indicated by :
at Hangfire.Storage.InvocationData.DeserializeJob()
As to the root cause of the problem, I was first thinking that the job had been enqueued with an older version of the framework, while the dequeue attempt was with a newer version of the framework. But this might also be a serialization settings issue, as stated by this older answer

Cannot import `Imports System.Web.Script.Serialization`

When I try to Imports System.Web.Script.Serialization, I get an error in VB 2010 that says:
Warning: Namespace or type specified in the Imports System.Web.Script.Serialization doesn't contain any public member or cannot be found. Make sure the namespace or the type is defined and contains at least one public member. Make sure the imported element name doesn't use any aliases.
Not sure why I can't import it.
You might be missing an assembly reference to System.Web.Extensions.dll. Add this reference to your project, then try again.
Generally speaking, when you encounter this issue, go to the .NET API reference page of the type you want to use — for instance, JavaScriptConverter — and look out for the Namespace and Assembly hints (make sure you're looking at the page for the .NET framework version that you are using):
Namespace: tells you what to put in the Imports directive.
Assembly: tells you what assembly you need to reference in your project (e.g. go to Solution Explorer, locate References, and select Add Reference… from the context menu).
Also make sure to check the "Target Framework" in the project properties. If you are targeting a "Client Profile" framework then the assembly System.Web.Extensions.dll will not be available to add as a reference to your project.

which reference should be added to wcf project so that program recognize requestUrl.GetComponents()?

I have copied a sample code to a wcf project and it contains $requestUrl.GetComponents$ ... the program don't recognize it ( there is red line under it) ... which reference should I add to solve the problem ...?
GetComponents is a method of the System.Uri class. You only need to reference the System.dll (which is on the great majority of the projects by default) to use that.

queryinterface for interface failed

I'm using an interop COM assembly in my 1.1 VB.NET code, and when I try to set a property of a class, I get an InvalidCastException with the message "QueryInterface for Interface … failed."
Any ideas on this?
First, make sure your COM component is registered with regsvr32.exe.
Then, make sure any necessary marshalling support is also registered -- these come in one of two kinds:
1) proxy/stub DLL, usually called <YourComponent>ps.dll -- register this too with regsvr32.exe
2) Associated type library -- register this with regtlib.exe
If you used tlbimp on your DLL, try using regtlib to register the DLLs type library.

CLSIDFromProgID is successful but CreateInstace fails! Why?

I am trying to create an instance of a COM object. I have the class name that implements the interface and I get a CLSID by using CLSIDFromProgID(). So since I am getting a CLSID I thought everything should be fine from now on. However when I do a call to CreateInstance and pass in the CLSID, I get an error saying "Class not registered". Also I get this error only in some computers. It runs error free on several computers. I don't understand where the problem could be. Is my registry dirty? Does anyone know what is going on here? Thanks for your help!
I just want to add that this is a .NET COM class. The appropriate entries are in the registry and the DLL is in the GAC.
CLSIDFromProgId is simply looking up the ProgId's name in the registry and translating it to a CLSID, it doesn't have to look at anything beyond the registry or even check that something is actually implementing that CLSID.
When you call CreateInstance on the CLSID, Windows will look up in the registry to find out how the object should be instantiated (usually a exe or dll). It will then try to load the dll (or start up the exe) and create the object from it.
There is a lot of documentation in MSDN on the processes involved, for example see "COM Class Objects and CLSIDs", and if you do a lot of COM work it is worthwhile learning the process from first principals since it can save a lot of time and hassle when debugging this type of issue.
It's a two step process in the registry. You used the ProgID to get the CLSID. Then, when you call CreateInstance, COM then uses the CLSID to find the path to the dll. You can used regedit yourself to lookup the CLSID and see what that entry looks like.
Thanks for your answers. The .Net assemblies were registered properly and were present in the GAC. One application that absolutely confirmed this was Process Explorer. You can view the dlls that are loaded by each application. So from here I was able to see if the application that was instantiating the COM objects was actually able to load the DLLs or not. I found out that this was indeed happening. The problem was due to different Regional settings. We found that the application threw an exception when the region was not set to US. This issue was fixed. The error message "Class not registered" was not very helpful. Thankfully it was a quick fix.
Using shell32 as an example, you can create a new instance like so;
var shl = (Shell) Activator.CreateInstance(Type.GetTypeFromProgID("Shell.Application"));
This will aquire a refernce to an existing component;
var shl2 = (Shell) Marshal.GetActiveObject("Shell.Application");
Here's a reference to how to do the same in IronPython.
** Note, this used the progid, clsid would be nearly identical, just use Type.GetTypeFromCLSID({GUID}).