Skip to content
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

Properly support framework multi-targeting #66

Open
artiomchi opened this issue Aug 10, 2017 · 2 comments
Open

Properly support framework multi-targeting #66

artiomchi opened this issue Aug 10, 2017 · 2 comments

Comments

@artiomchi
Copy link
Member

artiomchi commented Aug 10, 2017

At the moment, this is either ignored (best case), or no code will be identified by the compiler in the first place (worst case!)

When R4Mvc.Tools loads a web project, we have to identify the target framework of that project, and possibly configure MSBuild to pick a desired framework. Need to test that with multi targeted projects, as well as identifying the differences based on which framework comes first in that list.

@artiomchi
Copy link
Member Author

So, there's no perfect solution for this just yet, but I just came up with a pretty decent workaround that will let people use R4Mvc in their multi-targeted projects!

To do this, you'll have to change your csproj file to only use one framework when the project is built by R4Mvc using a build property, like follows:

<PropertyGroup Condition="$(IsR4MvcBuild) == ''">
  <TargetFrameworks>net462;netcoreapp2.1</TargetFrameworks>
</PropertyGroup>

<PropertyGroup Condition="$(IsR4MvcBuild) != ''">
  <TargetFramework>netcoreapp2.1</TargetFramework>
</PropertyGroup>

Your regular builds won't be affected, but R4Mvc will be able to handle it just fine.

Can't come up with a proper fix yet, as MSBuild seems to have some issues that doesn't make it easy to load multi-targeted projects (with dependencies that target other frameworks). I'll still keep an eye on this, and hopefully will eventually find a proper solution to this.

Buildalyzer is actually a great option as well, but at the moment it doesn't work either (thanks to a different issue with MSBuild!)

Until then, I'll leave this issue open. If anyone has an even better solution to this - help is always greatly appreciated!

@artiomchi
Copy link
Member Author

Moving this to v1 Backlog, since we now have a workaround in place, which makes the current library usable in multi targeted projects

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

No branches or pull requests

1 participant