sdk
sdk copied to clipboard
Could not copy the file deps.json because it was not found. Microsoft.Common.CurrentVersion.targets 4919
I updated VS 2019 to 16.9.4 version. Sometimes I am getting three errors on rebuilding solution:
Could not copy the file deps.json because it was not found. Microsoft.Common.CurrentVersion.targets 4919
Could not copy the file runtimeconfig.json because it was not found. Microsoft.Common.CurrentVersion.targets 4919
Could not copy the file runtimeconfig.dev.json because it was not found. Microsoft.Common.CurrentVersion.targets 4919
To reprodue this issue, get this project: https://github.com/komdil/MyProject/tree/reproduceSDKIssue Rebuild twice
The project strcuture like:
MyProject
project and MyProject.Model
have the same output path
I created issue on Visual Studio support: https://developercommunity.visualstudio.com/t/could-not-copy-the-file-depsjson-because-it-was-no/1400396 They mantion that it is started happening after this PR: https://github.com/dotnet/sdk/pull/14488
For workarround I removed these lines from Microsoft.NET.Sdk.targets:
<ItemGroup Condition="'$(GenerateDependencyFile)' == 'true'">
<AllItemsFullPathWithTargetPath Include="$(ProjectDepsFilePath)"
TargetPath="$([System.IO.Path]::GetFileName($(ProjectDepsFilePath)))"
CopyToOutputDirectory="PreserveNewest" />
</ItemGroup>
<ItemGroup Condition=" '$(GenerateRuntimeConfigurationFiles)' == 'true'">
<AllItemsFullPathWithTargetPath Include="$(ProjectRuntimeConfigFilePath)"
TargetPath="$([System.IO.Path]::GetFileName($(ProjectRuntimeConfigFilePath)))"
CopyToOutputDirectory="PreserveNewest" />
<AllItemsFullPathWithTargetPath Include="$(ProjectRuntimeConfigDevFilePath)"
TargetPath="$([System.IO.Path]::GetFileName($(ProjectRuntimeConfigDevFilePath)))"
CopyToOutputDirectory="PreserveNewest" />
</ItemGroup>
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.
@dsplaisted It will be good if you give us any workarround. It is slowing down our productivity. Removing lines from Microsoft.NET.Sdk.targets works but I am not sure it is good solution. Can it affect to other places?
Hi @komdil,
Let me try to explain what is happening.
Normally each project builds to a different output folder. When there is a ProjectReference between projects, the referencing project copies the necessary files from the referenced project's output folder to its output folder.
If each project builds to the same output folder, then the referenced project may try to write files to the shared output folder, and then the referencing project will try to copy the file from the same source to the same destination. When trying to do a clean / rebuild, it can end up deleting a file and then trying to copy that file, resulting in the errors you are seeing.
I told Sarah (and she told you) that we didn't support multiple projects using the same output directory. However, I wasn't aware of the UseCommonOutputDirectory at the time. With that property, it should be possible to have multiple projects use the same output directory (though it is not a very common scenario so it is more likely that there could be issues).
What that property does is it simply prevents any files from being copied from referenced projects. If all of the projects are building to the same output directory, then the referencing project doesn't need to copy files from the referenced project, because the referenced project already built them to the same output folder.
If you have a mix of projects, some of which use the same output folder, and some which don't, then UseCommonOutputDirectory
won't help you as much. This is because you need the files from the referenced projects copied for the projects that don't share an output directory, but setting the property to true stops that from happening for all projects. You may be able to set UseCommonOutputDirectory
to true and then add your own MSBuild logic for copying the files from referenced projects in a different folder.
This did change in 16.9 with #14488. This added additional files that would be copied as part of project references, which caused the issue to surface.
@dsplaisted Currently we have more than 30 projects in solution. Most of them have the same output and some of them not. That's why UseCommonOutputDirectory will not help us. We cannot saparate project outputs becasue of several reasons. One of them is som,e projects output will take more than 1 gb memory. The project depedencies is complex and when I saparate output, all outputs will take more than 30gb memory. Another thing is I am running some commands in BuildEvent. This command is expecting common output. And there are many other reasons.
I didn't understand what are you mean here:
If each project builds to the same output folder, then the referenced project may try to write files to the shared output folder, and then the referencing project will try to copy the file from the same source to the same destination. When trying to do a clean / rebuild, it can end up deleting a file and then trying to copy that file, resulting in the errors you are seeing.
When trying rebuild it will delete file and why it will try to copy it? Maybe it should build referenced project first, and then copy?
Maybe do you need copy files in different condition (instead of HasRuntimeOutput) because it is working when I clean solution and then rebuild
@dsplaisted Can we copy files if they exists? For example:
<Target Name="AddDepsJsonAndRuntimeConfigToCopyItemsForReferencingProjects"
BeforeTargets="GetCopyToOutputDirectoryItems;_GetCopyToOutputDirectoryItemsFromThisProject"
Condition="'$(HasRuntimeOutput)' == 'true'">
<ItemGroup Condition="'$(GenerateDependencyFile)' == 'true' and Exists($([System.IO.Path]::GetFileName($(ProjectDepsFilePath))))">
<AllItemsFullPathWithTargetPath Include="$(ProjectDepsFilePath)"
TargetPath="$([System.IO.Path]::GetFileName($(ProjectDepsFilePath)))"
CopyToOutputDirectory="PreserveNewest" />
</ItemGroup>
<ItemGroup Condition=" '$(GenerateRuntimeConfigurationFiles)' == 'true'">
<AllItemsFullPathWithTargetPath Include="$(ProjectRuntimeConfigFilePath)"
Condition="Exists($([System.IO.Path]::GetFileName($(ProjectRuntimeConfigFilePath))))"
TargetPath="$([System.IO.Path]::GetFileName($(ProjectRuntimeConfigFilePath)))"
CopyToOutputDirectory="PreserveNewest" />
<AllItemsFullPathWithTargetPath Include="$(ProjectRuntimeConfigDevFilePath)"
Condition="Exists($([System.IO.Path]::GetFileName($(ProjectRuntimeConfigDevFilePath))))"
TargetPath="$([System.IO.Path]::GetFileName($(ProjectRuntimeConfigDevFilePath)))"
CopyToOutputDirectory="PreserveNewest" />
</ItemGroup>
any progress? My PR was failed
I started encountering this issue when I converted a net 4.8 solution to the SDK project format using the upgrade assistant.
I only have 2 projects currently, but we have other solutions with 10+ projects that are 12 year old code that really do need the same output directory.
Is there any solution for this yet? If I drop a file "*.deps.json" that is empty in the shared output folder (set as ..\bin) it will build once, then fail again.
I really don't want to mess with build parameters just to fix this. We use Azure DevOps to build/release all of our applications and having project specific UseCommonOutputDirectory just seems messy.
If each project builds to the same output folder, then the referenced project may try to write files to the shared output folder, and then the referencing project will try to copy the file from the same source to the same destination. When trying to do a clean / rebuild, it can end up deleting a file and then trying to copy that file, resulting in the errors you are seeing.
What's the different between the dotnet
CLI vs. Visual Studio? I only notice this issue in Visual Studio.
I got these errors when upgrading from VS 2022 (v17.2) with .NET 6.0.302 to VS 2022 (v17.3) with .NET 6.0.400. The solution that worked for me was to add the following to a shared .props file e.g. Directory.Build.props
<ItemDefinitionGroup>
<ProjectReference>
<Private>false</Private>
</ProjectReference>
</ItemDefinitionGroup>
Hope this helps. [Caution: See correction in comment below]
Correction. The above solution fixes compilation to single "bin" folder. And unit tests run. But all executables fail to run. I've reverted this fix locally. Looks like using Clean Solution
and Build Solution
in Visual Studio is only current workaround for Rebuild Solution
failing.
I got errors like this in a unit test project after doing a Rebuild All:
error MSB3030: Could not copy the file "C:\Dev\SolutionDir\Bin\Debug\netcoreapp2.1\SomeProject.deps.json" because it was not found.
error MSB3030: Could not copy the file "C:\Dev\SolutionDir\Bin\Debug\netcoreapp2.1\SomeProject.runtimeconfig.json" because it was not found.
error MSB3030: Could not copy the file "C:\Dev\SolutionDir\Bin\Debug\netcoreapp2.1\SomeProject.runtimeconfig.dev.json" because it was not found.
It may have something to do with switching from VS 2019 to VS 2022; it's still a netstandard2.0 + netcoreapp2.1 solution.
The workaround that worked for me was to (1) Right-click SomeProject and Rebuild and (2) Build the solution (do not Rebuild). Still, I don't understand what is happening despite @dsplaisted's explanation.
We also encounter this issue on a 400+ project solution, we just cannot afford to build everything and copy everything in separate directory. This really need to be adressed
We also encounter this issue on a 400+ project solution, we just cannot afford to build everything and copy everything in separate directory. This really need to be adressed
For libraries targeting .NET, we don't copy the output of the referenced projects. Your app and test projects should have their dependencies copied to the output, but library projects shouldn't.
What does the structure of your projects and the references between them look like? How many app projects do you have compared to library projects?
The issue still exist on 2023.03.04. When you just clean solution and build solution again its working. But our CI/CD jobs doing rebuild. So it needs to be fixed soon. Thanks.
still having the same issue, the only workaround is to clean the solution, is there news on a lead to follow ?
Ditto. Build, Clean + Build work; Rebuild seems to below away the files of dependencies, but then not regenerate them?