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.

Sign up for GitHub

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

Jump to bottom

Need to backport #2501 to 1.x of DependencyModel #2887

Closed
eerhardt opened this issue Aug 23, 2017 · 7 comments
Closed

Need to backport #2501 to 1.x of DependencyModel #2887

eerhardt opened this issue Aug 23, 2017 · 7 comments
Assignees
@eerhardt
Labels
area-DependencyModel
Milestone
1.1.x

Comments

@eerhardt
Copy link
Member

Steps to reproduce

See dotnet/sdk#1488 for the issue

Try to build/run an ASP.NET 1.1 MVC app with the 2.0 SDK.

Expected behavior

It should work.

Actual behavior

InvalidOperationException: Can not find assembly file Microsoft.CSharp.dll at 'C:\Projects\Temp\VS2017Issue\WebApplication1\bin\Debug\net462\refs,C:\Projects\Temp\VS2017Issue\WebApplication1\bin\Debug\net462\

@Petermarcu @karelz @steveharter @nguerrera
@karelz
Copy link
Member

karelz commented Aug 23, 2017

I assume we have to service 2.0 for that, right?

@eerhardt
Copy link
Member Author

The necessary change is already in 2.0. The proposed fix here is to backport the change into 1.1.

The issue is that using the 2.0 SDK is breaking 1.1 MVC apps because it is copying files into the refs folder, which the 1.1 DependencyModel isn't expecting.

@karelz
Copy link
Member

karelz commented Aug 23, 2017

I thought we're using 2.0 SDK also for 1.1. Marking as 1.1.x then. Can you please send it to shiproom?

@karelz karelz changed the title Need to backport https://github.com/dotnet/core-setup/pull/2501 to 1.x of DependencyModel Need to backport #2501 to 1.x of DependencyModel Aug 23, 2017
@DamianEdwards
Copy link
Member

Seems this got dropped somehow? Are we intending to service this in the next 1.1.x patch? I just hit this issue myself trying to make a 1.1.x app targeting .NET Framework 4.6.1, and it's shown up in 2.1 E2E testing as a blocking issue.

@davidfowl @balachir

@eerhardt
Copy link
Member Author

eerhardt commented Apr 2, 2018

Yes, this got dropped. 😞 I'll get a PR for it into 1.1, and send a shiproom email.

@eerhardt eerhardt self-assigned this Apr 2, 2018
eerhardt referenced this issue in eerhardt/core-setup Apr 2, 2018
@eerhardt
AppBaseCompilationAssemblyResolver shouldn't throw.
e59b3ef 
There are scenarios where a compilation assembly should be resolved from places outside of the appbase folder in a published app.  We shouldn't throw early and let the other resolvers do their job.

Fix #2496
Fix #3081
@eerhardt
Copy link
Member Author

eerhardt commented Apr 2, 2018

@DamianEdwards - FYI dotnet/core-setup#3954 is the PR to backport the change into 1.1. Thanks for bringing this issue up.

eerhardt referenced this issue in dotnet/core-setup May 24, 2018
@eerhardt
AppBaseCompilationAssemblyResolver shouldn't throw.
d395623 
There are scenarios where a compilation assembly should be resolved from places outside of the appbase folder in a published app.  We shouldn't throw early and let the other resolvers do their job.

Fix #2496
Fix #3081
@eerhardt
Copy link
Member Author

Closing as the fix has been ported to 1.1.

@msftgits msftgits transferred this issue from dotnet/core-setup Jan 30, 2020
@msftgits msftgits added this to the 1.1.x milestone Jan 30, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 20, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@eerhardt eerhardt

Labels
area-DependencyModel
Projects
None yet
Milestone
1.1.x
Development

No branches or pull requests
4 participants
@DamianEdwards @karelz @eerhardt @msftgits