New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.NET Core sln template has issues referencing some assemblies #5498

Closed
rockfordlhotka opened this Issue Apr 7, 2018 · 3 comments

Comments

Projects
None yet
4 participants
@rockfordlhotka
Copy link

rockfordlhotka commented Apr 7, 2018

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 x.dll) but is built once for wasm and once for .NET Core - so there are two assemblies named x.dll but they are different builds of the same code.

(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 x.dll in the Blazor app, and the netcore-built x.dll in the server app, the server app will fail to build.

@aspnet-hello aspnet-hello transferred this issue from aspnet/Blazor Dec 17, 2018

@danroth27

This comment has been minimized.

Copy link
Member

danroth27 commented Jan 23, 2019

Hi @rockfordlhotka

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?

@danroth27 danroth27 self-assigned this Jan 23, 2019

@rockfordlhotka

This comment has been minimized.

Copy link
Author

rockfordlhotka commented Jan 23, 2019

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.

@danroth27

This comment has been minimized.

Copy link
Member

danroth27 commented Jan 23, 2019

Cool, sounds like we can close this one then. Thanks!

@danroth27 danroth27 closed this Jan 23, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment