Running "dotnet store" command fails with "MSB3026: Could not copy" errors

[livarcocc]

From @Petermarcu on February 21, 2018 1:41

@scottmendel commented on Tue Feb 20 2018

Issue Title

Be as descriptive as you can with your title.

General

Provide details on the problem you are experiencing including the .NET Core version, operating system version and anything else that is relevant.

Please provide a code sample for your issue if it is relevant, either inline, link to a gist (or similar) or add it as a zipped attachment.

For some issues, you will get a quicker and better response if you file it at a more specific .NET repo. For example, if the problem is with ASP.NET Core, you are encouraged to use the aspnet/home repo.

---

@scottmendel commented on Tue Feb 20 2018

Apologies, I submitted this accidentally while trying to fill in the details. I will try and reopen with details.

---

@scottmendel commented on Tue Feb 20 2018

I ran the following command: dotnet.exe store --skip-optimization -m "C:\Panorama\hedzup\mn\bin\InstallNetCore.manifest" -o "C:\Program Files\dotnet\store"

I received the following error: C:\Program Files\dotnet\sdk\2.0.0\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.ComposeStore.targets(351,5): warning MSB3026: Could not copy "C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.aspnetcore.antiforgery\2.0.0\lib\netstandard2.0\Microsoft.AspNetCore.Antiforgery.dll" to "C:\Program Files\dotnet\store\x64\netcoreapp2.0\microsoft.aspnetcore.antiforgery\2.0.0\lib\netstandard2.0\Microsoft.AspNetCore.Antiforgery.dll".

The assembly in question was in fact "in use" but I expect this is a problem that needs to be addressed. The Microsoft.AspNetCore.Antiforgery dll in the NuGetFallBackFolder I suspect is "Any CPU", at least the "Optional" PE header marks it with magic 0x10B. The same assembly in the store has a optional header with magic 0x20B which makes it an x64 version of the same assembly. The version of the assembly is the same in both cases 2.0.0.17205, so I am wondering why the copy is even attempted. because this is the "x64" area of the store, replacing the "x64 version of the assembly with the "Any CPU" version, this seems like it is undoing an optimization made previously.

I am attempting to add something to the store, but not this assembly. Microsoft.AspNetCore.Antiforgery is a dependency of another assembly that is the main target of the store command which is Riverbed.AppInternals.DotNetCore.dll. But the store command will not complete. I do understand that stopping the dotnet applications using the antiforgery dll will work around the problem, but we have a requirement to do a "hot" install on a production server where it is not desirable to stop services that are running.

If I remove the --skip-optimazation flag, I run into the reverse scenario; assemblies can be "in use" trying to place optimized version of the assemblies into the store area.

Conceptually, I would like the store command to add only the dependencies that are missing, and not get hung up on things that already may be in the store and possibly in use.

Environment Details:

.NET Command Line Tools (2.1.2) Product Information: Version: 2.1.2 Commit SHA-1 hash: 5695315371 Runtime Environment: OS Name: Windows OS Version: 10.0.16299 OS Platform: Windows RID: win10-x64 Base Path: C:\Program Files\dotnet\sdk\2.1.2\ Microsoft .NET Core Shared Framework Host Version : 2.0.5 Build : 17373eb129b3b05aa18ece963f8795d65ef8ea54

Copied from original issue: dotnet/core-setup#3712

[livarcocc]

From @steveharter on February 22, 2018 16:1

cc @livarcocc

[livarcocc]

This seems to me like a issue to write to the Program Files location. Can you run the store command above if you specify a different output folder? Or if you run with elevation?

[scottmendel]

Elevated permission is required. Specifying a different location will work, but it creates extra steps: it requires a series of commands to copy the files from the new location back to the store. Each copy command must first be gated by a check for the existence of the target to avoid the 'in use' entanglements. This also requires a lot of extra disk space as a large majority of the assemblies are already in the store. On its face value, it just seems wrong to want to try and replace an ngen-ed (optimized) target with one that is not optimized. My desired use case is to only add assemblies to the store that are missing and leave the things already there alone.

[livarcocc]

The dotnet store command is not intended for that. For you to overlay one store on top of another. It is meant to produce a store artifact which can then be installed separately. That's how we use for our own asp.net store and is how this came up.

Also, are you sure that you don't need elevated permission to write to that folder at all? Meaning, not just to overwrite existing files but also to be able to add new ones?

[scottmendel]

I think some more background information is appropriate. Forgive me, I was not sure what level of detail was require to get my issues addressed. Our team is attempting to profile a .Net core application using the ICorProfilerCallback interface. IL is re-written on the fly and new assembly references may be added that were not part of the original closure for the profiled application. Adding them to the store seems to be the only way to resolve those references at run time, keeping in mind that the profiled application cannot be rebuilt and redeployed with new references. It simply comes down to this: the rewritten IL may use a different set of .Net Core NuGet packages that the original application uses. Profiling .Net Core apps is fundamentally different than profiling older framework applications because the new framework is no longer monolithic. I can find no proper documentation on IL re-writing that may help with these fundamental issues.

[livarcocc]

I am sorry, I am not familiar at all with the IL re-writing process that you are describing above, but I wonder why running from elevation or copying the folder over would not work for you.

Like I said, you are currently using the tool in a way that it was not really designed for and we don't have plans to change it at the moment.

dotnet store produces a full closure of assemblies based on your project file.