0

Working in Visual Studio 2019, running the project in IisEpxress

I am trying to update all the projects in a solution from .NET Core 2.2 to 3.1. I have changed the versions and updated the NuGet packages of for example EntityFrameworkCore (this perticular one to 3.1.5).

In short the problem is that when I run my updated ASP.NET Core Web API project I get this error:

TypeLoadException: Could not load type 'WE.GPR.Connections.Common.DomainEntity' from assembly 'WE.GPR.Connections.Common, Version=1.0.22.0, Culture=neutral, PublicKeyToken=null'. Unknown location

The weird thing is that the model 'DomainEntity' is in the 'WE.GPR.Connections.Common.Models.DomainEntity' namespace. So it is looking in the wrong location. But when I build my solution, I get no errors.

The version of this solution that ran .NET Core 2.2 did not have this problem.

I did the same update process to another solution which uses the same project 'WE.GPR.Connections.Common'. That went fine, nothing like these errors.

It is a bit of a complex solution with submodules and custom NuGet packages from our own feed combined like so:

Root

  • Project 1
    • Custom NuGet package*
  • Project 2
    • Ref to Submodule project 3

Submodules

  • Submodule project 3

*this nuget package project also has the same project 3 as a submodule

So my first assumption was that that NuGet package was messing things up, as this was the only thing different from my other solution that I am able to successfully update to 3.1 (this last mentioned solution was actually the solution that produced this NuGet package).

So I made the Submodule into another NuGet package, but the problem remains.

I also removed the entire folder with the solution from my local system and cloned it again.

I even started a fresh update from the master branch and did all the updating again, but the problem remains.

When I do a search for the 'WE.GPR.Connections.Common' I cannot find it anywhere in the solution, apart from the usage with the .Model or other namespaces behind it.

I have spend several days now on this very annoying problem.

Do you have any ideas on how to approach this next, because I have ran out of ideas myself.

Update

Yesterday I pushed the code to Azure DevOps and the build ran into the same problems as me locally, so it is definitely not something with my machine.

Here is the full error message:

 Standard Output Messages:
 Application startup exception: System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types.
 Could not load type 'WE.GPR.Connections.Common.DomainEntity' from assembly 'WE.GPR.Connections.Common, Version=1.0.22.0, Culture=neutral, PublicKeyToken=null'.
 Could not load type 'WE.GPR.Connections.Common.DomainEntity' from assembly 'WE.GPR.Connections.Common, Version=1.0.22.0, Culture=neutral, PublicKeyToken=null'.
 Could not load type 'WE.GPR.Connections.Common.BaseDto' from assembly 'WE.GPR.Connections.Common, Version=1.0.22.0, Culture=neutral, PublicKeyToken=null'.
 Could not load type 'WE.GPR.Connections.Common.BaseDto' from assembly 'WE.GPR.Connections.Common, Version=1.0.22.0, Culture=neutral, PublicKeyToken=null'.
 Could not load type 'WE.GPR.Connections.Common.BaseDto' from assembly 'WE.GPR.Connections.Common, Version=1.0.22.0, Culture=neutral, PublicKeyToken=null'.
 Could not load type 'WE.GPR.Connections.Common.BaseDto' from assembly 'WE.GPR.Connections.Common, Version=1.0.22.0, Culture=neutral, PublicKeyToken=null'.
    at System.Reflection.RuntimeModule.GetTypes(RuntimeModule module)
    at System.Reflection.RuntimeAssembly.get_DefinedTypes()
    at Microsoft.AspNetCore.Mvc.ApplicationParts.AssemblyPart.get_Types()
    at Microsoft.AspNetCore.Mvc.Controllers.ControllerFeatureProvider.PopulateFeature(IEnumerable`1 parts, ControllerFeature feature)
    at Microsoft.AspNetCore.Mvc.ApplicationParts.ApplicationPartManager.PopulateFeature[TFeature](TFeature feature)
    at Microsoft.AspNetCore.Mvc.ApplicationModels.ControllerActionDescriptorProvider.GetControllerTypes()
    at Microsoft.AspNetCore.Mvc.ApplicationModels.ControllerActionDescriptorProvider.GetDescriptors()
    at Microsoft.AspNetCore.Mvc.ApplicationModels.ControllerActionDescriptorProvider.OnProvidersExecuting(ActionDescriptorProviderContext context)
    at Microsoft.AspNetCore.Mvc.Infrastructure.DefaultActionDescriptorCollectionProvider.UpdateCollection()
    at Microsoft.AspNetCore.Mvc.Infrastructure.DefaultActionDescriptorCollectionProvider.Initialize()
    at Microsoft.AspNetCore.Mvc.Infrastructure.DefaultActionDescriptorCollectionProvider.get_ActionDescriptors()
    at Microsoft.AspNetCore.Mvc.ApiExplorer.DefaultApiVersionDescriptionProvider.EnumerateApiVersions(IActionDescriptorCollectionProvider actionDescriptorCollectionProvider)
    at Microsoft.AspNetCore.Mvc.ApiExplorer.DefaultApiVersionDescriptionProvider.LazyApiVersionDescriptions.EnumerateApiVersions()
    at System.Lazy`1.ViaFactory(LazyThreadSafetyMode mode)
    at System.Lazy`1.ExecutionAndPublication(LazyHelper executionAndPublication, Boolean useDefaultConstructor)
    at System.Lazy`1.CreateValue()
    at System.Lazy`1.get_Value()
    at Microsoft.AspNetCore.Mvc.ApiExplorer.DefaultApiVersionDescriptionProvider.get_ApiVersionDescriptions()
    at WE.UserPortal.Api.Startup.<>c__DisplayClass5_0.<Configure>b__0(SwaggerUIOptions options) in D:\a\1\s\WE.UserPortal.Api\Startup.cs:line 130
    at Microsoft.AspNetCore.Builder.SwaggerUIBuilderExtensions.UseSwaggerUI(IApplicationBuilder app, Action`1 setupAction)
    at WE.UserPortal.Api.Startup.Configure(IApplicationBuilder app, IHostEnvironment env, IApiVersionDescriptionProvider provider) in D:\a\1\s\WE.UserPortal.Api\Startup.cs:line 127
    at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor, Boolean wrapExceptions)
    at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
    at Microsoft.AspNetCore.Hosting.ConfigureBuilder.Invoke(Object instance, IApplicationBuilder builder)
    at Microsoft.AspNetCore.Hosting.ConfigureBuilder.<>c__DisplayClass4_0.<Build>b__0(IApplicationBuilder builder)
    at Microsoft.AspNetCore.Hosting.ConventionBasedStartup.Configure(IApplicationBuilder app)
    at Microsoft.Extensions.DependencyInjection.AutoRegisterMiddleware.<>c__DisplayClass4_0.<Configure>b__0(IApplicationBuilder app)
    at Microsoft.AspNetCore.Mvc.Filters.MiddlewareFilterBuilderStartupFilter.<>c__DisplayClass0_0.<Configure>g__MiddlewareFilterBuilder|0(IApplicationBuilder builder)
    at Microsoft.AspNetCore.Hosting.WebHost.BuildApplication()
Daniël Tulp
  • 1,745
  • 2
  • 22
  • 51
  • do you clean debug and release folder ? – foad abdollahi Jul 12 '20 at 13:18
  • Yes, I did a clean and rebuild several times and even removed the entire clone from my machine and recloned it from our GIT repo – Daniël Tulp Jul 12 '20 at 14:51
  • I'd be looking at something like this that explains a web.config reference breaks it in IIS https://stackoverflow.com/a/2531775/495455 or there is a dependency issue in the Project that conflicts with something in `WE.GPR.Connections.Common`, some type of namespace ambiguity or NuGet version conflict https://stackoverflow.com/a/55565841/495455, or where it can't link/build it and [Fusion Viewer Log](https://learn.microsoft.com/en-us/dotnet/framework/tools/fuslogvw-exe-assembly-binding-log-viewer) might be worth a shot on the server. – Jeremy Thompson Jul 13 '20 at 08:29
  • @jeremy I think fuslogvw.exe is for .NET framework – Daniël Tulp Jul 14 '20 at 05:20
  • Full-Framework only are you saying? The 1st problem is **web.config reference breaks it in IIS**. I was thinking about this and the dependencies might be a problem as might the linking, but if it builds locally then that's your smoking gun. – Jeremy Thompson Jul 14 '20 at 05:27

1 Answers1

1

We have been able to solve above issue, the actual problem was not all our custom NuGet packages were updated to .net core 3.1. One custom NuGet package (Custom NuGet package 2) was still on .net core 2.2 and it uses out dated version of WE.GPR.Connections.Common (which was also on .net core 2.2) in it.

Root

Project 1

Custom NuGet package 1

Custom NuGet package 2

Project 2

Ref to Submodule project 3

Submodules

Submodule project 3

By removing Custom NuGet package 2 it worked for us as it was no longer used or referred in our project else we could just update it to .net core 3.1 as well.

Though the error thrown was irrelevant but theoretically all Custom NuGet packages and submodules must be updated to .net core 3.1 version.

Jeremy Thompson
  • 61,933
  • 36
  • 195
  • 321
Tejas Kumbhar
  • 26
  • 2
  • It comes down to the .Net Core BCL & etc NuGet libraries being modular and having subtle dependency issues: https://stackoverflow.com/questions/55161834/microsoft-aspnetcore-app-versioning-should-it-be-referenced-in-non-asp-net-c/55565841#55565841 – Jeremy Thompson Jul 14 '20 at 05:31
  • yes and the error message being not helpful at all, if it would also include where the reference was coming from, we would not have spend several days looking for it.... – Daniël Tulp Jul 17 '20 at 11:32
  • another problem was that the nuget packages were not using their own .Common project that was included in their build, but the one present in the Root solution, a third problem was that it did add any warnings or error messages that a referenced NuGet package was build on .NET Core version 2.2 – Daniël Tulp Jul 17 '20 at 11:35