Updating to 3.11-preview1 fails

[WolfgangHG]

Use the sample attached to #113 (it is a 4.6.1 project), compile it and update the Nuget package to 3.11-preview1.

This fails for me with an error:
The package at '...\RoslynTest\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.3.6.0' failed to uninstall. Restart Visual Studio to finish the process.

Restarting VS does not work, as the project is broken afterwards: "packages.config" has already an entry for the new version, but the project reference is missing.
It works better if I update the sample project to 4.8 before - now the same error is shown by VS, but the project reference is present after restarting VS.

It would probably work if I used a package reference instead of "packages.config".

Do you have any idea? Is this something that can be fixed?

Here is the output of Nuget console - the file "DotNetCompilerPlatformTasks.dll" is locked:

Attempting to gather dependency information for package 'Microsoft.CodeDom.Providers.DotNetCompilerPlatform.3.11.0-preview1' with respect to project 'RoslynTest', targeting '.NETFramework,Version=v4.6.1'
Gathering dependency information took 10 ms
Attempting to resolve dependencies for package 'Microsoft.CodeDom.Providers.DotNetCompilerPlatform.3.11.0-preview1' with DependencyBehavior 'Lowest'
Resolving dependency information took 0 ms
Resolving actions to install package 'Microsoft.CodeDom.Providers.DotNetCompilerPlatform.3.11.0-preview1'
Resolved actions to install package 'Microsoft.CodeDom.Providers.DotNetCompilerPlatform.3.11.0-preview1'
Executing script file '...\RoslynTest\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.3.6.0\tools\net45\uninstall.ps1'...
Removed package 'Microsoft.CodeDom.Providers.DotNetCompilerPlatform.3.6.0' from 'packages.config'
Successfully uninstalled 'Microsoft.CodeDom.Providers.DotNetCompilerPlatform.3.6.0' from RoslynTest
Adding package 'Microsoft.CodeDom.Providers.DotNetCompilerPlatform.3.11.0-preview1' to folder '...\RoslynTest\packages'
Added package 'Microsoft.CodeDom.Providers.DotNetCompilerPlatform.3.11.0-preview1' to folder '...\RoslynTest\packages'
Added package 'Microsoft.CodeDom.Providers.DotNetCompilerPlatform.3.11.0-preview1' to 'packages.config'
Executing script file '...\RoslynTest\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.3.11.0-preview1\tools\install.ps1'...
Restored system.codedom compiler for extension '.cs'.
Restored system.codedom compiler for extension '.vb'.
Successfully installed 'Microsoft.CodeDom.Providers.DotNetCompilerPlatform 3.11.0-preview1' to RoslynTest
Removing package 'Microsoft.CodeDom.Providers.DotNetCompilerPlatform.3.6.0' from folder '...\RoslynTest\packages'
Access to the path '...\RoslynTest\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.3.6.0\tasks\DotNetCompilerPlatformTasks.dll' is denied.
Access to the path 'DotNetCompilerPlatformTasks.dll' is denied.
Removed package 'Microsoft.CodeDom.Providers.DotNetCompilerPlatform.3.6.0' from folder '...\RoslynTest\packages'
Executing nuget actions took 2,48 sec
Time Elapsed: 00:00:02.6478401
========== Finished ==========

[StephenMolloy]

This is a bug in the nuget package listing. 4.6.1 is not a supported framework, so the package shouldn't work. 4.6.2 is the minimum framework version for the 3.11 package. The nuget listing says 4.6 though. :( The listing will be updated to 4.6.2 in future updates.

[WolfgangHG]

And what about the error when the project is switched to 4.8 before updating the package? Here, the package is updated after migration, but the DLL is also locked before.

[StephenMolloy]

Sorry, I kind of skimmed over that part. I figured the missing updated reference was the main issue.

To be honest, I don't know why that error appears. Obviously it appears that somebody has locked the file. I don't think it's us. It might be a third party tool or AV or something? (NuGet/Home#1458) I haven't seen this in my personal upgrade testing. Does this happen consistently? Do you have a small repro you can share?

[WolfgangHG]

Disabling all third party extensions and the virus scanner did not make a change.

But I think I have an explanation now: the problem seems to be caused by the fact that my sample zip does not contain the subdir "packages".
The error message can be reproduced with those steps:
a) unzip my sample and open solution
b) compile (directory "packages" is created)
c) update "Microsoft.CodeDom.Providers.DotNetCompilerPlatform" to 3.11-preview1 => error is shown.

It does not happen when:
a) unzip my sample and open solution
b) compile (directory "packages" is created)
c) restart Visual Studio
c) update "Microsoft.CodeDom.Providers.DotNetCompilerPlatform" to 3.11-preview1 => it works

So, this might be a NuGet issue. But it is probably not a realistic scenario - I should have added the "packages" dir to the zip.

By the way: installing 3.11 to the 4.6.1 project also works ;-).

[StephenMolloy]

My apologies. My reading comprehension was not very good last week apparently. :( You did have a repro project and steps laid out and I missed it.

Anyway, looking closer at this today, I can see what's going on now. In your case, msbuild.exe (spawned by VS when you build) has loaded our build tasks dll (introduced in 3.6 because inline 'CodeTaskFactory' is not supported by 'dotnet msbuild' which runs on .Net Core even though it can compile netstandard projects - see #51 and #92) and thus the task dll can't be deleted when uninstalling the 3.6 package. However, VS does keep track of this failure and will remove the old package after restarting. So at the end of the day everything works out fine despite the scary warning bar.

This isn't a new or unique to this package issue unfortunately. Here are some other threads I've come across while looking into this issue:

• https://social.msdn.microsoft.com/forums/vstudio/en-US/b6ad25c0-1762-4821-a3e4-1c6b5369c2b8/msbuild-doesnt-release-custom-tasks-assemblies-after-compile
• https://social.msdn.microsoft.com/Forums/en-US/4d67b00b-07ef-4fa3-b581-234fca5caac0/task-dll-is-locked-after-build
• https://stackoverflow.com/questions/4460721/custom-msbuild-task-locks-assembly
• https://stackoverflow.com/questions/3371545/visual-studio-2008-locks-custom-msbuild-task-assemblies

Seems like there has been some effort to fix this in the 'dotnet msbuild', but not the normal msbuild VS uses. If this were truly a breaking/blocking issue, it sounds like it might be possible to bring our custom tasks back inline and choosing between 'CodeTaskFactory' and 'RoslynCodeTaskFactory' using mechanisms similar to those employed in this blog post. But I remember considering 'RoslynCodeTaskFactory' when I was working on #51 and was running into a whole host of other problems with that approach. (I don't remember what those issues were off the top of my head. Maybe something like what is discussed in this thread?) We also can't take the wrapper approach described in some of those linked threads since the wrapper would have to be declared in either another .dll that we still can't unload, or an inline code task which brings us back to #51.

There are a few things that can be done to avoid or resolve the issue:

• Use 'PackageReference' - PackageReference keeps nuget packages in a global cache, so it doesn't actually delete the old package. It leaves the package alone in the cache and only removes references from the project which should work without a glitch.
• MSBUILDDISABLENODEREUSE=1 - According to this thread, setting this environment variable will stop VS from using a long-running msbuild, which is the process keeping our task dll alive. It's probably not worth disabling this feature just to avoid this rare inconvenience. But it's an option I guess.
• Or just restart VS. Either before or after updating the package. VS will make it right either way.

[WolfgangHG]

Thanks for the detailed analysis!

Yes, "PackageReferences" would be preferred, but just for the recoed: it does not work for old style Web projects.

[CZEMacLeod]

@WolfgangHG PackageReference can be used with Web Application Projects (ASP.Net 4.x) - I'm not sure if you meant Web Site projects (where I think you are correct).
You can also use the new SDK style projects for old WAP ASP.Net 4.x projects if you need to.
There is a thread dotnet/project-system#2670 that talks about it - or you can use the MSBuild.SDK.SystemWeb SDK to do it.
Full disclosure - I maintain the latter project and I also must admit I am being very remiss, as I haven't had a chance to test 3.1.1-preview1 yet, although I don't believe it will have any issues.