I am using a "custom" object builder (Autofac) so I can re-use the registration of many types that I have done in a common assembly. When I run the service, hosted within NServiceBus.Host.exe, I get the following error:
SerializationException was unhandled:
Type 'Autofac.Core.Registration.ComponentNotRegisteredException' in assembly 'Autofac, Version=3.0.0.0, Culture=neutral, PublicKeyToken=17863af14b0044da' is not marked as serializable.
This seems odd to me because NServiceBus uses Autofac by default and doesn't have this same issue.
I am using Autofac v 3.1.1 and NServiceBus 4.0.3
It's true that the ComponentNotRegisteredException is not marked serializable - Portable Class Libraries don't support the SerializableAttribute and Autofac 3.0+ is a PCL.
I'm guessing the larger issue you're running into isn't the SerializationException so much as the problem causing it - that something in your custom code isn't registered, so when some type is getting resolved it can't be built and, thus, Autofac throws that ComponentNotRegisteredException and NServiceBus is trying to serialize it.
Instead of trying to solve the serialization problem, I'd start looking at the source of the ComponentNotRegisteredException and focus on that.
The simplest way to diagnose these kind of issues is to turn on break on all exception in Visual Studio and see where it booms out first time.
9/10 is a problem with the initialization code.
I ran into a similar error while adding NServiceBus.Distributor.Msmq (4.4.2) to an old solution using NServiceBus 4.4.2. Turned out I'd forgotten to set up the NSB license for the new project. Trying to start the distributor threw this until I included a valid License.xml file in the build output:
Unhandled Exception: System.Runtime.Serialization.SerializationException: Type 'Autofac.Core.DependencyResolutionException' in assembly 'NServiceBus.Core, Version=4.4.0.0, Culture=neutral
PublicKeyToken=9fc386479f8a226c' is not marked as serializable.
Related
I have a .NET Core test project. In this, I need to call WebApi and WCF services (as we have migrated only some of our projects and I need to generate test data using old and new services). I have added the System.ServiceModel.Primitives package to the project but I still get this exception:
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
---> System.TypeLoadException: Could not load type 'System.ServiceModel.ServiceBehaviorAttribute' from assembly 'System.ServiceModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.
Has somebody an idea what I could have missed?
I found out that there were a lot of missing references in my project, none of them related to WCF directly. When debugging with breakpoints on the exceptions, I added the missing packages one after the other. In some cases, I found online that there is just an exception in .NET Core and you can't do anything for it, and have to just ignore it. Quite strange but at the end my tests were running.
I still have no idea why the exception from the question was occurring but it disappeared once all of the required references were available. Maybe something wan't building correctly before that and so the WCF package wasn't loaded?
Never mind, should you get such a message, just enable breakpoints on all exceptions and debug to see what is really going on.
I have a console application in netcoreapp3.1 that use a netstandard2.0 plugin.
The plugin reference a class library and implement an interface
All dll dependencies are in the the plugin folder and the plugin.dep.json include all referenced library.
When I run:
AssemblyLoadContext.Default.LoadFromAssemblyPath("path/to/main_myplugin.dll");//load plugin
it resolve the type of interface
When i try to run an instance as given below it fail:
if (type != null) //type is resolved and not null
{
var instance = (IContract)Activator.CreateInstance(type); //instance is created
Console.WriteLine($"Create instance : {instance.GetType()}"); // ok instance is created
var ret = instance.Execute(); //!!!fire exception here
Console.WriteLine(ret);
}
and fire error message:
System.IO.FileNotFoundException: 'Could not load file or assembly 'MyLibObjectsLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.'
If I loaded all dependencies, it works fine.
Should I load all dependencies when using AssemblyLoadContext.Default or it's a bug?
I asked this question in the dotnet project
All credit go to #vitek-karas.
The detailed answer is:
Currently this is by design. LoadFromAssemblyPath as well as any other LoadAssembly-like methods only ever load that assembly, they don't try to load a "plugin". For this case to work you would need the AssemblyDependencyResolver and hook it up to the Default ALC (probably via the Resolving event), and hope that there are no collisions between the host app and the plugin (since they will share all dependencies) and so on. Generally this is why it's better to load plugins into their own ALCs as that creates the necessary isolation and also makes it easy to hook up AssemblyDependencyResolver.
Higher-level answer - in 3.0 we didn't try to provide a "plugin load" API as there were too many open questions in how it should behave (the exact isolation behavior is very tricky to get right so that it would work for most use cases). Instead we provided the necessary building blocks (ALC, ADR, diag improvements, ...) and rely on users to write the cca 20 lines of code to implement the custom ALC. In 5.0 we are improving diagnostics by adding detailed tracing around the entire assembly binding process, that should help debugging issues when loading assemblies in general, but specifically when implementing custom ALCs.
Last week I upgraded my .NET Core Web API from 2.2 to 3.0.
I had a lot of issues with packages and still struggling.
Case 1: What I have right now is that all of my tests are failing:
unit tests, integrations tests, etc.
I'm using:
Nunit (3.12.0)
NUnit3TestAdapter (3.15.1)
Moq 4.13.0
Microsoft.NET.Test.sdk (16.2.0)
Microsoft.AspNetCore.Mvc.Testing
When I start debugging my tests I get the following error message:
System.IO.FileNotFoundException HResult=0x80070002
Message=Could not load file or assembly 'Microsoft.IntelliTrace.Core, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.
Source=System.Private.CoreLib.
The error occurred in the RuntimeAssembly file (part of system.private.corelib), method InternalLoadAssemblyName.
When I continue I get this:
System.Reflection.ReflectionTypeLoadException: 'Unable to load one or more of the requested types.
Could not load file or assembly 'Microsoft.IntelliTrace.Core, Version=16.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.'
Case 2: When I'm not debugging my tests but just run my application en startup swagger, I can use every call but my output window is filled with thousands of Exceptions like thrown:
'System.InvalidCastException' in Swashbuckle.AspNetCore.SwaggerGen.dll
This happens when the Linq class Where.SpeedOpt.cs is used and the List.cs class of generic, also in System.Private.CoreLib.
Are case 1 and case 2 related to each other?
Anyone have a workaround or solution?
Case 1 also fixed:
When using .Net Core 3.0 and automapper
you should add automapper with additional parameter
services.AddAutoMapper(typeof(Startup));
In .Net core 2.2 i just had
services.AddAutoMapper();
He fails on this during unit and integrationtesting
not on normal startup
Case 2 (swagger error) is solved.
Seems there was a bug in the swagger 5.0.0 packages
That bug is solved in the 5.0.0-rc4 version
Case 1 is still open.
I tried to reproduce with different coding and see what the results are.
When i instantiate a new httpclient, there is no error.
Nevertheless, i can not call my api because it's secured and i get the "unathorized" error (normal behaviour)
When i instantiate a new httpclient with my webapplicationfactory, there is the error.
Is there something that is not initialized from startup when i run my tests
instead of running the core api thru normal startup and calling swagger?
Maybe a problem in startup that is only an issue in unit and integrationtests?
Regards
GSharp
I recently took a legacy WCF project with Entity Framework 4 and upgraded it to EF6 and .NET 4.0. I took the legacy Silverlight client project and upgraded as well. Problems started to arise when I added a new service reference to the upgraded WCF service. The code generated in the service reference has conflicts and will not compile.
My initial problem is that both Microsoft.Data.Services.Client and System.Data.Services.Client are part of the references…
CS0433 The type 'EntitySetAttribute' exists in both
'Microsoft.Data.Services.Client, Version=5.6.4.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35' and 'System.Data.Services.Client,
Version=5.0.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
This surprises me even more when I look at the generated code, References.cs, that fails. The usage is fully qualified.
[global::System.Data.Services.Common.EntitySetAttribute("myTable")]. Apparently both assemblies use the exact same namespace.
If I remove Microsoft.Data.Services.Client I get:
Error CS1061 'myEntities4' does not contain a definition for
'DefaultResolveType' and no extension method 'DefaultResolveType'
accepting a first argument of type 'myEntities' could be found (are
you missing a using directive or an assembly reference?)
If I remove System.Data.Services.Client I get:
Could not load file or assembly 'System.Data.Services.Client,
Version=5.0.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or
one of its dependencies. The system cannot find the file specified.
This error is found in the XAML of a UserControl that uses a RadDataServiceDataSource.DataServiceContext.
I have spent quite a few hours trying several different paths including:
Getting older versions of Microsoft.Data.Services.Client from NuGet.
Using only one of the references, as mentioned above.
Changing the references in the WCF service before adding the Service Reference in the client.
Attempting advanced options when adding the Service Reference
Reuse all type from assemblies.
Reuse types in specified referenced assmeblies.
I have read the following posts, but they did not help:
Microsoft.Data.Services.Client.dll vs System.Data.Services.Client.dll
WCF error: Need to exclude all but one of the following types. Only matching types can be valid references
Project does not build after updating a service reference
I'm now considering building a new WCF and Web project to work around these issues. This should be an lengthy undertaking as well, and hopefully not a red herring.
Is this an artifact of upgrading from older versions of Silverlight, WCF, Entity Framework, or .NET in general? Please help me if you know what this is, or you have seen this before. A complete rewrite of the project to another platform is not an option unfortunately.
you can use this code :
EFContext.Configuration.ProxyCreationEnabled = false;
EFContext.Configuration.LazyLoading = false;
I am getting the following error in Quartz.net
The assembly with display name 'Quartz.XmlSerializers' failed to load
in the 'LoadFrom' binding context of the AppDomain with ID 1. The
cause of the failure was: System.IO.FileNotFoundException: Could not
load file or assembly 'Quartz.XmlSerializers, Version=2.0.1.100,
Culture=neutral, PublicKeyToken=null' or one of its dependencies. The
system cannot find the file specified.
It's very odd since Quartz.XmlSerializers does not exist anywhere in any code I'm using. It's not in the Quartz source code, my code, and none of my dependencies best I can tell. It only occurs when I debug my project, but not when I download the Quartz 2.0.1 source code and run the server from there.
I am using topshelf as the service install library.
It occurs during deserialization on line 226 of XMLSchedulingDataProcessor.cs of the Quartz source.
// deserialize as object model
System.Xml.Serialization.XmlSerializer xs = new System.Xml.Serialization.XmlSerializer(typeof(QuartzXmlConfiguration20));
Any clue to solving this would be helpful as I'm stumped by this error.
In applications that use XmlSerialization, you can get a first-chance exception in outside code when the application looks for a cached serialization assembly. You can find more information in this question.