Error running the sample under 2.0
andrewlock opened this issue · comments
The sample app runs fine under 1.0 and 1.1, but when I run it under 2.0 I get the following error, and the app fails to start up:
Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'System.ComponentModel.Primitives, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
at Microsoft.Extensions.FileProviders.PhysicalFileProvider.CreateFileWatcher(String root)
at Microsoft.Extensions.FileProviders.PhysicalFileProvider..ctor(String root)
at Microsoft.AspNetCore.Hosting.Internal.HostingEnvironmentExtensions.Initialize(IHostingEnvironment hostingEnvironment, String applicationName, String contentRootPath, WebHostOptions options)
at Microsoft.AspNetCore.Hosting.WebHostBuilder.BuildCommonServices(AggregateException& hostingStartupErrors)
at Microsoft.AspNetCore.Hosting.WebHostBuilder.Build()
at TagHelperPack.Sample.Program.Main(String[] args)
I also have a couple of questions based on your comments on the community standup:
It also shows how you can target multiple versions of ASP.NET Core with a library
The TagHelperPack project itself targets netstandard1.6, so can be consumed by any version, but doesn't the Microsoft.AspNetCore.Mvc.Razor version of 1.0.4 tie you to 1.0? When it's used in an app, I get that the app will drag that up, but when you use it in a 2.0 app, isn't there a risk of issues arising due to that? I assume the binding redirects are handled automatically?
Wouldn't a better approach be to target both netstandard1.6 and netstandard2.0, and then conditionally target the 1.0.4 or the 2.0.0 version of Microsoft.AspNetCore.Mvc.Razor, depending on the installation target?
Appreciate any guidance!
As an example, this is the approach I took in a library that contains a custom middleware:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<VersionPrefix>0.4.1</VersionPrefix>
<TargetFrameworks>net451;netstandard1.3;netstandard2.0</TargetFrameworks>
</PropertyGroup>
<ItemGroup Condition="'$(TargetFramework)' != 'netstandard2.0'">
<PackageReference Include="Microsoft.Extensions.Options" Version="1.0.2" />
<PackageReference Include="Microsoft.Extensions.DependencyInjection.Abstractions" Version="1.0.2" />
<PackageReference Include="Microsoft.AspNetCore.Http.Abstractions" Version="1.0.3" />
</ItemGroup>
<ItemGroup Condition="'$(TargetFramework)' == 'netstandard2.0'">
<PackageReference Include="Microsoft.Extensions.Options" Version="2.0.0" />
<PackageReference Include="Microsoft.Extensions.DependencyInjection.Abstractions" Version="2.0.0" />
<PackageReference Include="Microsoft.AspNetCore.Http.Abstractions" Version="2.0.0" />
</ItemGroup>
<ItemGroup Condition=" '$(TargetFramework)' == 'net451' ">
<Reference Include="System" />
<Reference Include="Microsoft.CSharp" />
</ItemGroup>
</Project>
For those dependencies, it shouldn't really matter. WRT to the error you're getting, I'd need to see your project file to know more.
The project file was the project from the sample folder 🙂 https://github.com/DamianEdwards/TagHelperPack/tree/master/samples/TagHelperPack.Sample
Seems the sample has a bug in the project file as it's specifying both <TargetFramework> and <TargetFrameworks>. I'll fix that up.
On your other suggestion though, I'm not sure that suffices, as for example it assumes that when you're running on a netstandard2.0 compatible runtime you want version 2.0 of the ASP.NET Core packages. However, ASP.NET Core 1.x runs on .NET Framework 4.6.1+, which are netstandard2.0, so this kind of conditional dependency on version 1.x vs. 2.0 of the packages is problematic.
You could possibly add a conditional group for net461 and align those with the 1.x packages, which would at least line up 1.x and 2.0 packages for folks running on .NET Core 1.x vs. 2.0, but folks on .NET Framework will still end up with a netstandard1.x lib coming in and its dependencies will get lifted to those used by the application. Which is completely fine by the way. .NET Core doesn't require binding redirects, and .NET Framework ASP.NET Core apps are just console apps, so the binding redirects should get created by default.
Seems the sample has a bug in the project file as it's specifying both and . I'll fix that up.
Cool, I thought that was just something to keep VS happy!
That's a good point about running ASP.NET Core 1.x on netstandard2.0 compatible frameworks, it rather messes up all my logic 🙁 It feels like supporting both 1.x and 2.x is going to be more hassle than it's worth, especially if you're relying on APIs that are breaking between them (e.g. auth).
Thanks for the info anyway, feel free to close this once the sample's fixed 🙂
Fixed 0c3a257