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

.Net Core 3 : InvalidOperationException when calling ResolveReferencePaths on a referenceassembly #3794

Closed
kYann opened this issue Oct 7, 2019 · 12 comments

Comments

@kYann
Copy link

kYann commented Oct 7, 2019

Describe the bug

On Asp .Net Core 3 getting referencePaths for all reference assembly throw a InvalidOperationException, it used to work on Asp .Net Core 2.

To Reproduce

Steps to reproduce the behavior:

Use Asp .Net Core 3
Run this code at the end of Startup.Configure

var context = DependencyContext.Load(typeof(Startup).Assembly);

var references = context.CompileLibraries.SelectMany(library => library.ResolveReferencePaths()).ToList();

See error : InvalidOperationException

Expected behavior

I expect to have all the reference paths like I used to have in Asp .net Core 2

Additional context

DepencyModel is used to load assembly to create Roslyn compilation. It is used by RazorLight and this library is often used for email generation.

@vitek-karas
Copy link
Member

@kYann Is this the exception you get?

System.InvalidOperationException: Cannot find reference assembly 'Microsoft.AspNetCore.Antiforgery.dll' file for package Microsoft.AspNetCore.Antiforgery

(Just want to make sure I'm trying to debug the same problem)

@kYann
Copy link
Author

kYann commented Oct 7, 2019

Yes exactly ! The exception happens for all referenceassembly type because the DependencyModel resolver does not find the SDK assemblies.

@vitek-karas
Copy link
Member

Thanks, I can repro the problem. Unfortunately this is probably a bigger problem introduced by changes to how shared frameworks are packaged in 3.0. I'm trying to put together the whole story of what we changed and why, to come up with a solution.

@nguerrera
Copy link
Contributor

nguerrera commented Oct 7, 2019

It was known that there would be cases where more reference assemblies would need to be copied to the output. I think what's happening here is ASP.NET Core is avoiding copying those refs on the basis that it is pre-compiling views. If you were to use the runtime compilation package, or set PreserveCompilationReferences=true, I believe it would work as in 2.2. Looking for relevant SDK issue to link.

@kYann
Copy link
Author

kYann commented Oct 7, 2019

PreserveCompilationReferences=true does not work

@nguerrera
Copy link
Contributor

I will take a look at that.

See https://github.com/dotnet/cli/issues/10502 for some discussion on this.

@nguerrera
Copy link
Contributor

cc @pranavkm

@vitek-karas
Copy link
Member

I just tried with adding

    <PreserveCompilationReferences>true</PreserveCompilationReferences>

Into the project and now it seems to work.
Note that once you build it you should now see a refs folder in the output.

@kYann
Copy link
Author

kYann commented Oct 7, 2019

On an Asp .Net core project it does not work. But adding :
<PackageReference Include="Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation" Version="3.0.0" />
Make it works

@vitek-karas
Copy link
Member

Not sure what you mean by ASP.NET core project - I tried it on a the project I get by running dotnet new web.

@nguerrera
Copy link
Contributor

nguerrera commented Oct 7, 2019

Possibly an incremental build issue when PreserveCompilationReferences is changed? I believe that is what that package does (sets that same bool), possibly the new package ref forced the build to be less incremental?

@kYann
Copy link
Author

kYann commented Oct 7, 2019

My bad, I was refering to the PreserveCompilationContext parameters. Thanks a lot, it works !

@kYann kYann closed this as completed Oct 7, 2019
@msftgits msftgits transferred this issue from dotnet/core-setup Jan 30, 2020
@msftgits msftgits added this to the 3.1 milestone Jan 30, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 12, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants