Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
.NET Core sln template has issues referencing some assemblies #5498
The .NET Core hosted template has an issue where it can't reference some assemblies or NuGet packages.
Suppose you have a component that has the same assembly name (like
(This scenario might seem odd - but it isn't uncommon, especially with something like Blazor where the mono runtime on the client is not the same as the netcore runtime on the server. The solution is to have a codebase that is "the same" except with compiler directives to fix the differences between platforms. Yes, netstandard should fix this, but is not a perfect solution.)
Right now, if you reference the mono-built
We don't have a TFM for mono.wasm. We currently just use .NET Standard to target mono.wasm. So you could build your component library to target both .NET Standard and .NET Core. Is that what you're currently doing?
As for the build failure your seeing, it sounds like that happens because your are using two different builds of the same assembly in the same app. Why would you need to do that?
At the time I created this issue it was impossible to get all the same behaviors without using compiler directives - hence a different assembly for Blazor from the .NET Standard one on the server.
Subsequently I figured out a way to refactor the code to live within the Blazor limitations, and implemented that code for .NET Standard as well.
As long as the mono-wasm implementation of .NET Standard isn't too leaky going forward we should be fine.
The specific code is the same issue Newtonsoft.Json and other serializers face with optimizing away reflection through the use of expression trees. That doesn't work in mono-wasm, but does work on other platform implementations. So in my case I included branching code via a config switch (I couldn't find a way to auto-detect that we're running in mono-wasm) to use the ancient reflection-only code vs the expression tree code.
Basically, on mono-wasm the developer needs to make sure to configure my library to use the compatible implementation, everywhere else the default is to use the modern implementation.