I recently installed VS2012. A C++ project (with .Net 4.0) that compiles fine under VS2010 is not recognizing HashSet<T> on VS2012. I even tried being explicit with following declaration:
System::Collections::Generic::HashSet< String^ >^ _reasons;
But that only results in the error:
error C2039: 'HashSet' : is not a member of 'System::Collections::Generic
The documentation says it's in System.Collections.Generic. The C++ compiler doesn't think so.
Any ideas on where it went?
HashSet<> was a late addition to .NET, it became available in .NET 3.5. The namespace is older, mscorlib.dll contained classes in System::Collections::Generic since .NET 2.0, classes like Stack<> and Queue<>. HashSet<> got added in a new assembly for .NET 3.5, System.Core.dll, they didn't want to tinker with the 2.0 assemblies.
Accordingly, you must add a reference to System.Core to avoid the error message.
Always refer back to the MSDN documentation when you get an error like this, it shows you want assembly reference is required.
Related
During migration of our existing project targeting .NET framework 4.8 we encountered starnge error:
MC1000 Unknown build error, 'Could not find type 'System.Web.PreApplicationStartMethodAttribute' in assembly 'C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.5\ref\net6.0\System.Web.dll'.'
error message image
Basically we have one big class library targeting net6.0-windows that has been used across multiple different smaller projects.
This class library is compileable as a stanalone porject with no errors, but as soon as we reference it in our WPF project, also targeting same net6.0-windows, we got this error.
Does anyone experiencing sme problem?
Any help appreciated...
Eventually I found that mixing of ASP.NET components together with WinForm or WPF is not allowed anymore. So solution was to split our library file into two separate DLL assemblies each targeting proper SDK.
Maybe this header isn't decribe my problem exactly, but...
I have .NET Core console app project which uses C++/CLI project written as a wrapper for native C++ code from same dll.
So, both C# and C++/CLI project are compiled well, but when I run C# project, I get this error:
Could not load file or assembly 'Microsoft.VisualC.STLCLR, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.
I checked this file on my disk - I have it installed in many directories on it. I wrote all paths I've found in the PATH enviroment variable, but no effect.
My configuration:
Windows Server 2016, .NET Core 3.1.102, MSVS 2019 16.4.3.
Please, can someone say me the reason of this error and give me a correct solution? Thnxs.
P.S. IF it needs I can add classes and data I use in my code.
P.P.S. I have it works under .NET Framework 4.8, but not .NET Core 3.1
I downloaded Microsoft.VisualC.STLCLR dll from
C:\Windows\Microsoft.NET\assembly\GAC_MSIL
and I put it on my repository and references it on my .net core project it works.
I am having the same error while migrating from .NET Framework 4.8 to .NET 6.
I tried to copy the dll side by side with my binaries but with no success.
Procmon did not even list any read of the DLL (I am an happy user of Procmon for many years).
To bypass the runtime error, I removed uses of the cliext namespace in our C++/CLI code.
In my case, I had to convert code depending on :
#include <cliext\set>
#include <cliext\functional>
#include <cliext\vector>
#include <cliext\algorithm>
The exception occured after a call to a method which was using one of the cliext container.
By chance, the amount of conversion work was minimal.
How to add standard .Net references such as
using System.Drawing;
using System.Drawing.Drawing2D;
using System.Drawing.Imaging;
When trying
using (System.Drawing.Image I)
I get the error
Severity Description File Line
Error The type name 'Image' could not be found in the namespace 'System.Drawing'. This type has been forwarded to assembly 'System.Drawing.Common, Version=0.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcdxxxxx' Consider adding a reference to that assembly.
When going into reference VS 2018 wants me to point to the DLL File.
Its really frustrating. This is a Asp.NetCore MVC web based project.
System.Drawing is incompatible with .NET Core, because it uses Windows-specific APIs not available in .NET Core. Microsoft has since released System.Drawing.Common, which is a NuGet package that provides a similar API to the old System.Drawing but uses cross-platform APIs. To make this truly a drop-in replacement, the System.Drawing namespace now forwards to System.Drawing.Common, so older code could work without change.
Long and short, you need to add the System.Drawing.Common NuGet package to your project.
I have an EXE in VB6 that calls a recently upgraded to VB.Net DLL. This part is working fine, but the issue that I am running into is related to locating the interop of another COM DLL the VB.Net DLL references.
An overview: EXE (VB6) calls method A of DLL (VB.Net), no issues. Method A of DLL calls method B of third party DLL (COM), it gets an error of not being able to find the interop file of the COM DLL.
I have tested directly in VB.Net using a test UI to call the same method A in the VB.Net DLL, and everything works fine. I am currently at a loss as to what is causing the issue.
Thanks,
Chris
I have finally found the answer to the issue. All said and done, the issue was that the interop assemblies were framework version 4.0 instead of framework version 2.0. Visual Studio created them this way for some reason, so I had to change them by using Visual Studio 2008 to create new versions of them.
The process to find this out (which most of is already stated above, but repeated here for helpfulness) was to place all my VB.NET dlls and the interop assembly dlls in the directory of the VB6 exe. (I created sub folders for each one for easier cleanup later.) This still resulted in the same error, but the assembly builder log showed a different reason for the error. This time it was able to load the assembly without issue, but was not able to complete the setup of the assembly.
Researching this led me to the idea of checking the framework versions of the interop assemblies using ILSpy to find out they are version 4.0 while my dlls are version 2.0.
Initially I tried recreating them in Visual Studio 2017, since my project uses framework 2.0, but it still created them as framework 4.0 for some reason. I then tried in Visual Studio 2008, and it was able to create the correct framework 2.0 versions of the interop assemblies, and now everything works as expected.
I was having issues in log4net when I updated my solutions to .net 4.0 , and then I downloaded the source of it and built log4net and targeted it to .net 4.0 and used it in my projects.
Initially when I referred log4net that is targeted to run time 2.0 it complied and run the application but log did not work.
Now when I run my project with log4net targeted to .net 4.0 I get the error "The type initializer for 'Log4NetTest.TestLog' threw an exception."
Any Idea how to solve this?
Edit: this is the inner exception:
InnerException: System.TypeLoadException Message=Inheritance security rules violated while overriding member:
'log4net.Util.ReadOnlyPropertiesDictionary.GetObjectData(System.Runtime.Serialization.SerializationInfo, System.Runtime.Serialization.StreamingContext)'.
Security accessibility of the overriding method must match the security accessibility of the method being overriden.
Source=log4net
TypeName=log4net.Util.ReadOnlyPropertiesDictionary.GetObjectData(System.Runtime.Serialization.SerializationInfo, System.Runtime.Serialization.StreamingContext)
StackTrace:
at log4net.Repository.Hierarchy.Hierarchy..ctor(ILoggerFactory loggerFactory)
at log4net.Repository.Hierarchy.Hierarchy..ctor() in C:\src\Repository\Hierarchy\Hierarchy.cs:line 150
In the log4net source code, add a [SecurityCritical] attribute to the
Util.ReadOnlyPropertiesDictionary.GetObjectData method and build.
Just compiled the source for target framework 4.0 (not client). Source code of version 1.2.11 already contains this attribute, but be sure to use 'NET_4_0' as a compiler argument. Otherwise, this attribute will not be added.
I've found a compiled version of log4net for .NET client profile here:
http://gosheg.blogspot.com/2011/04/log4net-in-net-40-c-applications-net.html
This worked for me:
In the log4net source code, add a [SecurityCritical] attribute to the Util.ReadOnlyPropertiesDictionary.GetObjectData method and build.
There might be some other things you'll need to do to get it to build for the 4.0 framework.
See this post:
Weird override problem with Fluent NHibernate and .NET 4
I have fixed the similar issue by simply updating the Log4Net package from Visual Studio package manager.
Thanks,
Khachatur
I Fixed it by adding [assembly: System.Security.SecurityRules(System.Security.SecurityRuleSet.Level1)]
to log4net AssemblyInfo but now its not logging