I am trying to upgrade an old asmx webservice to Web API. Idealy I would like to use .Net Core as that is what we have been developing in. The issue is that the API must communicate with a legacy system using a COM object.
I have copied over the dll (already not ideal, I know) and, the .Net Core API project is able to add it as a reference and the code all compiles. However, on running the code I get the following error when instantiating an object from the dll:
Retrieving the COM class factory for component with CLSID
{CCA0B90B-DFDE-4DD3-9C7B-9769A3F12201} failed due to the following error:
80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).
I've tried to do exactly the same thing using the full .Net framework and everything works as expected so I imagine it is an issue with Core - maybe the portability requirements.
It will not be possible to rewrite the integration to the legacy system at this point and I was just wondering if there was any way around this without using the full .Net framework.
Update
I don't know if this will help but I can created a .Net Framework console app which runs the code just fine. when I reference the project from my .Net Core API and call the exact same code the error above still occurs.
Related
My understanding is that, starting with ASP.NET Core 3.0, .NET Framework is an unsupported target framework, and thus you can only run on the .NET Core runtime.
If this is the case, what NuGet packages can be imported into an ASP.NET Core 3 app?
I assume that you could reference any package that targets netstandard, but what about packages that only target the full framework (i.e., a legacy package that only targets net45)?
What happens if the package you import references an assembly that's not part of .NET Core—i.e., System.Drawing?
TL;DR: You can still reference (packages which depend upon) .NET Framework assemblies from .NET Core 3 and even .NET 5, but you will receive a runtime error if you call into any code which relies upon APIs or libraries not (yet) supported by .NET Core. You can discover these using Microsoft's .NET Portability Analyzer
Background
First off, you're correct that ASP.NET Core 3.x applications can no longer target the .NET Framework, as announced by Microsoft in 2018. That capability previously allowed ASP.NET Core applications to call into .NET Framework libraries, and thus offered an intermediate solution for web applications migrating to .NET Core.
Note: Since the .NET Framework only runs on Windows machines, writing ASP.NET Core web applications which targeted the .NET Framework implicitly restricted those applications to running on Windows.
Behavior
Even when targeting .NET Core or now .NET 5, however, you're still able to reference .NET Framework packages and assemblies, assuming you're on a Windows machine and have the corresponding .NET Framework installed. The inner workings of this are a bit involved, but the short of it is that .NET Core and .NET 5 will evaluate .NET Framework assembles as though they are .NET Standard assemblies. If the API call is also implemented in the .NET Core runtime, it will work fine—but if the API call is exclusively part of .NET Framework, you'll receive an exception.
Surprise! It's really important to emphasize that this is a runtime exception. You will still be able to reference the .NET Framework assembly, write calls to problematic members, and compile your code without any warnings. But as soon as you call into code dependent on a .NET Framework-specific assembly, you'll receive the runtime exception.
Example
With .NET 3.0, a significant portions of .NET Framework libraries have been ported over to .NET Core. In fact, this includes most of the System.Drawing libraries you referenced as an example—though there are good reasons you may not want to use them. If you dig a bit deeper, however, there are plenty of libraries which remain unsupported. One obvious example is the WebConfigurationManager, which could be used to access configuration settings from web.config files.
.NET Framework Code
So, as an example, let's say you have the following function in a .NET Framework class library, which returns an array of keys from your web.config's <AppSetting>s element:
public static class Configuration
{
public static string[] GetAppSettings() => System.Web.Configuration.WebConfigurationManager.AppSettings.AllKeys;
}
ASP.NET Core Code
And then, in an ASP.NET Core controller, you expose an endpoint to retrieve this data:
public class MyController: Controller
{
public IActionResult ApplicationKeys() => Content(String.Join(", ", Configuration.GetAppSettings()));
}
Exception
In an ASP.NET Core 2.x application targeting the .NET Framework, this will work just fine. In an ASP.NET Core 3.x or ASP.NET Core 5 application, however, you'll receive the following runtime error when you call the /My/ApplicationKeys/ route:
System.TypeLoadException: 'Could not load type 'System.Web.Configuration.WebConfigurationManager' from assembly 'System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.'
Avoiding Surprises
If you're anything like me, this will make you incredibly nervous. You'd much rather receive design-time errors—or, at least, compile-time warnings—as soon as you attempt to call into a library relying upon unsupported code. Fortunately, Microsoft offers a .NET Portability Analyzer, which is also available as a Visual Studio Extension, for exactly this purpose.
As of .NET 5, there's also a compatibility analyzer built into the SDK which will identify calls that are not supported by the .NET 5 runtime on particular platforms. This requires that target libraries explicitly annotate their types with the [SupportedOSPlatform()] attribute, so you won't get any warnings for legacy .NET Framework types. But this will help identify similar types of compatibility issues for libraries targeting a variety of platforms.
Example
If you run the Portability Analyzer on the above sample code, for example, it will output an Excel spreadsheet identifying that T:System.Web.Configuration.WebConfigurationManager is Not Supported in e.g. .NET Core,Version=v3.1 or .NET Standard + Platform Extensions,Version=v2.0.
Note: Microsoft used to offer an API Analyzer as a NuGet package, which promised to provide design-time analysis in Visual Studio. Unfortunately, the code hasn't been updated in two years, and the latest release is 0.2.12-alpha. In my evaluation, it was not effective at identifying issues.
Sample Project
I've put together a sample project on GitHub which demonstrates the above behavior. It includes the following projects:
ASP.NET Core 2.0 Website targeting .NET Framework 4.8
ASP.NET Core 3.1 Website targeting .NET Core 3.1
.NET Framework class library with calls to the legacy WebConfigurationManager
Both ASP.NET Core websites include two endpoints which call into the same .NET Framework 4.8 class library. The first is a "Hello world" example which will execute fine on both projects, since it relies exclusively on common APIs:
http://localhost:5000/Basic/Index
The second will fail on the ASP.NET Core 3.1 project, since it calls into the legacy WebConfigurationManager API:
http://localhost:5000/Basic/Configuration
Disclaimer: This is a quick and dirty repository that I put together to verify my understanding prior to posting this. If there's interest, I'll tidy it up and document it. For now, however, it may prove useful for those of you who need to see this in action.
Acknowledgments
#Chris Pratt offered an excellent answer covering similar material last year. It's worth reading.
I have some legacy .NET code that I would like to wrap with an API.
The code is a mixture of ASP.NET Webforms and .NET Framework 4.0
I'm hoping to use the new ASP.NET Core Web API and have created a new solution based on this framework and added the legacy code as existing projects.
Everything builds OK but when I try and call some of the legacy code I get the following error:
System.TypeInitializationException occurred HResult=0x80131534
Message=The type initializer for 'TreeManager' threw an exception.
Source=
Inner Exception 1: FileNotFoundException: Could not load file or
assembly 'System.Web.Extensions, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35'. The system cannot find the file
specified.
This is the code I call:
TreeManager.LoadEvent += LoadTree;
public class TreeManager
{
...
public static event EventHandler<LoadEventArgs> LoadEvent;
...
}
I tried updating the legacy code to .NET 4.5.2 but get the same error.
I wrapped the legacy code with an API using ASP.NET MVC 4 API 2 and all worked well.
Is it possible to do this and, if so, what changes do I need to make?
First, you can choose to target either .NET Core or the full framework with a ASP.NET Core app. Just because it's "Core" doesn't mean you have to use .NET Core with it. If you're utilizing legacy APIs, you may be forced to run on the full framework.
If you need or simply want to use .NET Core, so that the app can be deployed outside of a Windows environment, then you'll need to migrate any APIs that aren't supported to alternative APIs or potentially rewrite functionality if no alternative API exists.
.NET Core 2.0 supports .NET Standard 2.0, which has a very large API footprint. Because of this, Microsoft opened up compatibility with legacy .NET Framework libraries and packages. However, no guarantees are made that you can fully utilize those libraries and packages. Just because you can add the dependency doesn't mean you can utilize all the APIs. That's likely what you're running into here. This particular set of APIs has a dependency on System.Web, which is not a part of .NET Core.
Recently, Microsoft has released some tools to make migration scenarios like this easier. First, there's the .NET API Analyzer, a NuGet package which will add Intellisense callouts to API calls that are not compatible with various targets. This will help you track down code that needs to be changed, and alert you when you're writing new code, that you need to do things in a different way than you might be used to.
Second, there's the Windows Compatibility Pack for .NET Core, another NuGet package that shims in support for a lot of older Windows-only APIs from the full framework. This can give you a bit of breathing room during your migration, reducing the amount if things you need to change, somewhat. Though, you are still encouraged to switch out this code eventually as well, eventually weaning your application off of the dependency altogether.
Finally, if none of this helps, you may simply have to find an alternative. That might require installing a third-party NuGet and rewriting some code to work with that instead of what you were using before.
No one ever claimed migrating was easy; it's always an uphill battle. If you don't have the bandwidth to do it now, simply target the full framework and call it a day. Otherwise, dig in and tackle it as best you can.
I am in the process of writing a .NET wrapper for legacy native c++ code. My strategy is to write a CLR class library that wraps the native code.
To test whether the class library is functioning properly, I created two console apps in separate solutions:
A C++ CLR console app
A C# console app
Both of these contain the same simple test code to exercise the class library.
Both apps build as expected. The C++ app runs just fine, but the C# app is giving me a FileNotFoundException when it tries to load my class library.
I have a constraint that forces me to use VS2008 and .NET 3.5. Everything is built with Win32 or x86 configurations.
For both console apps, I am using a project reference to the class library.
In each case, builds copy the dll (and the intermediate files) to the same directory where each app is built.
I tried using the fusion log viewer, but logs are disabled on my machine and I do not have administrator privileges.
Has anyone ever seen this before?
Can someone please point me to a good site that outlines the differences between the way C# and C++ CLR apps load assemblies?
Since this is my first attempt to bridge C++ and C# I assume I am just making a simple mistake somewhere, but I am stumped as to what that is.
I have trolled the internet (including many SO postings) but have yet to find exactly what I need.
Thanks in advance,
Judd
I have an application that consists of a client-side application and a WebApi website.
My client-side stuff is targetting .NET 4 so that I don't have to insist that users install .NET 4.5. My website, however, is entirely under my control, so I'm targetting .NET 4.5.
There is one shared assembly, which I use for data access. It uses Entity Framework 5.
When I build the client application, the DLL used is version 4.4.xxx, whereas when I build the web application, the DLL is 5.0.xxx.
Up until now, I've been able to run the client application with no problems, and I've also been able to run the web application, again without problems.
However, I've now re-created my web application project from scratch (*), and suddenly I can't run it. I get a YSOD saying "Could not load file or assembly 'EntityFramework, Version=4.4.0.0 ..." at the point where my data-access assembly is first invoked.
Now, it's perfectly clear what that error means - it can't find the v4.4 DLL as used by the data-access assembly - but I don't understand why that's a problem with my new project when it wasn't a problem with my old project. As far as I can see, the same DLLs are referenced in each project.
(*) I should explain why I'm re-creating my project. I originally created the project in VS 2012 RC, and then later upgraded to the release version. Although this supposedly upgraded my project, I've had a few problems with it, and have also noticed some differences v. a newly-created project. So, to be on the safe side - and hopefully circumvent those other problems - I'm re-creating it from scratch.
So, my question: why is this suddenly a problem, and what can I do to resolve it?
Is the code depending on the assemblies set to require the exact version? If so, you will need a publisher policy for the EntityFramework assembly or bindingRedirect for the referencing application (web project).
I have a COM+ application that has been exported to an MSI using Component Services and then installed on a test server. The web application (ASP) is unable to instantiate any of the objects it uses from the COM+ application.
The COM+ application consists of three DLLs built in VB6. There is one DLL each for data, application and presentation layers. The web application only uses objects from the presentation layer. The COM+ DLLs call into a couple of .NET DLLs exposed via COM.
When the web application runs, an HTTP 500 - Internal Server Error is returned. No errors appear in the application or system log.
I've tried instantiating the objects from VBScript using WSH.CreateObject and it works only for objects in the data layer. When trying to create object in the application or presentation layer I get the following error:
Error: Could not create object named "My.ProgId"
Code: 800A801D
Source: WScript.CreateObject
Because it fails from VBScript, I suspect that the ASP app is fine and that it is the COM+ application that has issues.
Extra Info
If I uninstall the COM+ application and try to run my VBScript to test instantiation, I get a different error.
Error: Could not locate automation class named "My.ProgId"
Code: 80020009
Source: WScript.CreateObject
Since the errors are different, it seems that COM is at least finding the COM+ objects when they're installed, it's just not able to instantiate them.
I've also tried monitoring the script with ProcessMon. I can see WScript.exe (via COM) querying the registry for the ProgID, and then the CLSID. Eventually the path to the DLL is pulled back and then svchost.exe and dllhost.exe query the registry for the same information using the CLSID and also getting back the path to the DLL. Eventually the DLL has a Load Image operation against it followed by the same for msvbvm60.dll. I don't see anything that points to a failure accessing the COM+ DLL.
I've now tried installing the COM+ application to another Win2k3 server and a Windows XP desktop. I'm getting the same result with being able to instantiate objects from the data layer DLL, but not from the application and presentation layer DLLs. I've also tried getting an old copy of the application layer DLL and I am able to successfully instantiate objects from it. However, when I compare the project files for the two different versions, nothing stands out as being a possible cause of this problem.
The application layer DLL was referencing a struct defined in a .NET assembly. The error was caused by the type library containing the struct not being registered on the deployment machine.
When building the .NET assembly in Visual Studio, it would create a type library for the assembly and register it. When the app was deployed, the .NET assemblies were registered using regasm /codebase <assemblyname.dll>. That would register the classes so that they could be instantiated, but it did not register any structs.
The solution was to use regtlib.exe to register the type library on the test server.
The error messages were of no help at all when trying to discover the cause of the problem. Come on Microsoft!!