We have a solution in .NET Core 3.1 with multiple project. All project have same build output.
This worked fine until recently a build start failing on all machines. (Some update?)
Build works
Rebuild fails.
Clean + Rebuild works.
I can reproduce the issue in Visual Studio and in the Rider as well.
The root cause is following:
Rebuild start building every project in parallel as separate task. Each task first delete output folder and then build a project.
Because all project have same output folder and run in parallel, they just delete files created by another project build which result into error:
Microsoft.Common.CurrentVersion.targets(4919, 5): [MSB3030] Could not copy the file "C:\myproject\x64\Debug\Project1.deps.json" because it was not found.
Microsoft.Common.CurrentVersion.targets(4919, 5): [MSB3030] Could not copy the file "C:\myproject\x64\Debug\Project1.runtimeconfig.json" because it was not found.
Microsoft.Common.CurrentVersion.targets(4919, 5): [MSB3030] Could not copy the file "C:\myproject\x64\Debug\Project1.runtimeconfig.dev.json" because it was not found.
Obviously a simple solution would be to do separate output folder, but I cannot do this because another tools expect this structure and because it is kind of rule.
I would like to clean the output on rebuild first before each project clean+build is trigger.
Another solution I can imagine is to generate deps.json, runtimeconfigs files into separate folder.
Is there any solution for this?
Maybe you Can set project dependencies in solution properties... that way they should be forced to build one after the other. eg. A depends on B , B on C
You should probably not change the build output paths, simply do a publish?
Related
I have a .Net Core 3.1 DLL project that all of a sudden didn't build anymore with the following error message:
CSC : error CS2012: Cannot open 'some.dll' for writing -- 'Access to the path 'some.dll' is denied.'
This project is not under any kind of source control. It's not on a build server (what most questions on Stack Overflow is about). It's a project on my local machine.
Now, to rule out Visual Studio I've tried to build it from the command line with dotnet. Same thing unfortunately. Things I've tried:
Close Visual Studio, delete obj folder + bin folder
Delete the entire project and made a new one with the same name
Removed project reference to other project (to rule out: dotnet core build in parallel or simultaneously)
The suggestions here error CS2012: Cannot open <executable path> access to <executable path denied>
This all didn't help. Then I had success for 1 build with:
Changing the target framework from 3.1 to 3.0
Changing the name of the project
This built the project once, because the filepath changes really, but then I got the same error the 2nd built.
Then I've had a few days success by:
Moving the entire solution to a new folder without the problematic project. Then adding a brand new project and adding the code to this complete new project.
But unfortunately after a few days I got the exact same problem. I have no idea what changed. It's always this project (which is a unittest project) and not the other project that it references (also a DLL project). I am out of ideas. Anybody have any suggestions for me to try?
Thanks in advance for helping.
Update
My project's name = "TheGenesysProject.Engine.Test" and it was indeed quarantined by my company's security software as Pavel said in the comments. So I changed it to "JustSomeLib" and the security software didn't quarantine it anymore! Why this is, I have no clue whatsoever...
Update 2
it must be something in the project itself and not the name of the dll. I restored JustSomeLib so it had the same NuGet packages (xunit + xunit.runner.visualstudio) plus .cs files (just 3 files with some unittests in them nothing fancy) as TheGenesysProject.Engine.Test and it all build and worked once! Then I coded some more stuff. Added an unittest to test my new code and... Bam! In quarantine again. What the heck?! I am just logging this for if people have the same problem as I do.
Update 3
Just to conclude this story. The folder with sourcecode is now excluded from the malware scan and the dll's are not put in quarantine. This solved this problem. Thank you Pavel.
I want to build my project from TFS Azure(VSTS).
I have made one project which is under Asp.Net Core.
I have made Build definition with Asp.Net Core Template and given the path for restore like **\*.csproj but I am not sure about this path or not?
I have tried many options like **\admis.csproj and some others, but I have faced the same error as the one on the following image:
I am using Asp.Net Core 2.1. Any ideas?
Just check your Workspace mappings in Get sources step, make sure you have mapped the source directory which included the solution or project file *.csproj:
Please check!
1) Server path should be: $/YourDevOpsProjectName/YourBranchName/TheRestPathUntil .csproj file
As I see on your screenshot, your path should be $/0424Test/NetCoreApp/NetCoreApp (I'm assuming that your .csproj file is there).
2) I had the same problem, because when I tried to Queue build for my project, in Source version I set 1 and the process of the queue tried to take 1 source code version, that of course not exists.
If Source version's value is empty, it try to get the last version of your source code
3) Use **/*.csproj as "Path to project(s)" for every task in your Agent job.
Please check!
Server path should be: $/YourDevOpsProjectName/YourBranchName/TheRestPathUntil .csproj file
We're using Visual Studio Team Services with Git as the source control system and I've configured a build which executes successfully online. Ideally I'd like to:
After building the site in VSO, precompile and dump the aspx and .dll files to the git repository
On the on-premises web server, pull from git and move to our staging site
The second part I can figure out on my own, but the documentation for VSTeam seems sketchy on how to dump the compiled sources to git. I've kept the default build configration almost the same as the default with the exception of a Powershell script which is supposed to create artifacts for the drop. Despite this, the drop.zip file create is empty.
The following is how my build definition is set up in VSO.
Instead of the PowerShell script, you'd be able to use the "Copy and Publish artefacts" and have it create a specific artefact with the specific bits you need:
This will automatically create a named build artefact which you can then use from Release Management as an input.
The PowerShell script was used in the XAML builds when used with the "Project Output | As Configured" option.
To create your "packaged" website, you need to add a couple of parameters to the MsBuild/Visual Studio Build step to instrict the compiler to package your website:
/p:DeployOnBuild=true /p:DeployTarget=Package
/p:SkipInvalidConfigurations=true /p:PackageAsSingleFile=false
/p:AspNetCompileMerge=true
Optionally you can configure your target directory as well using
/p:PackageLocation="$(Build.BinariesDirectory)\Published"
If you do this, you need to configure this directory as your copy root in the copy and publish task.
I did a quick look at the Power-Shell script, there are two issues with it:
It still use the variables like "$Env:TF_BUILD_SOURCESDIRECTORY" which does not exist in VSTS(VSO). See Variables for VSTS.
It copies the files from "BUILD_SOURCESDIRECTORY" folder to "BUILD_BINARIESDIRECTORY". But the "Publish Build Artifacts" step in your definition publish the files in "BUILD_ARTIFACTSTAGINGDIRECTORY" folder.
So if you want to use this script, you need to update the script to remove the "TF_" string in the variables and update the "Publish Build Artifacts" step to publish the files in "BUILD_BINARIESDIRECTORY" folder(Set Path to Publish to: $(Build.BinariesDirectory)).
However, if you want to copy and publish the website files, you can simply add one more argument in "MSBuild Arguments" section of "Visual Studio Build" step:
"/p:outdir=$(build.artifactstagingdirectory)"
Remove the Power-Shell script step and the other steps just keep default settings.
Or you can also change the settings of "Copy Files" steps to select the files/folders you'd like to copy.
We've got an Asp.Net web application we're trying to get pseudo-deployed to a folder, and I'm starting to think Microsoft are crazy -- why is it so hard to get a WAP to do a "Local FileSystem" deploy as part of MSBuild?
I can build with this:
msbuild .\SubSite.csproj "/p:Platform=AnyCPU;Configuration=Release" /t:Package
And get a nice package.zip which I can deploy to a website...
However, I have two projects in my solution, which I need to combine before I ship them, so I want to deploy both packages into a folder, and then re-package that folder. Despite the documentation on technet to the contrary, it doesn't seem to be possible to do:
msdeploy -verb:sync -source:package=.\SubSite.zip -dest:contentPath=.\Www\SubSite
Because you get the error:
Source (sitemanifest) and destination (contentPath) are not compatible for the given operation.
Does anyone have a suggestion of how I could web deploy two sites inside one another without manually copying files out of a "PackageTmp" folder? I mean, I'm aware that I could just skip zipping the package and manually copy the files out to do this, but I'm not happy about having to create a custom target, and there's no other way to find that just to do something that should be built in.
We did eventually figure out how to do this, but I'm not really happy about it ;-)
Basically, (as mentioned elsewhere on so), you can call msbuild with the target set to _WPPCopyWebApplication. You can also specify/override the WebProjectOutputDir property when you do that. Something like this (where ${name} are variables we're using)
msbuild ${SourcePath}\Www\UI\UI.csproj "/p:Platform=AnyCPU;Configuration=Release;WebProjectOutputDir=${OutputPath}\AppRoot" "/t:_WPPCopyWebApplication"
msbuild ${SourcePath}\Www\Mobile\Mobile.csproj "/p:Platform=AnyCPU;Configuration=Release;WebProjectOutputDir=${OutputPath}\AppRoot\Mobile" "/t:_WPPCopyWebApplication"
msbuild ${SourcePath}\Www\Service\WebService.csproj "/p:Platform=AnyCPU;Configuration=Release;WebProjectOutputDir=${OutputPath}\AppRoot\WebServices" "/t:_WPPCopyWebApplication"
We can then package up the whole "AppRoot" in a separate step.
If you have a project that builds one project before building the next, but the next needs to know the 'path' of the first build, is it possible to get this?
For example:
Project A has Build Configuration A and Build Configuration B.
Build Configuration B has a dependency on Build Configuration A. From without the Build Configuration B it will need access to the path of Build Configuration A. Is there are a way to obtain this?
Most simple approach would be to define a custom checkout directory in the A and use the same hard-coded value in B.
If you use TeamCity snapshot or artifact dependencies, you can use %dep.btXXX.teamcity.build.checkoutDir% to get checkout directory of the dependency build. However, this will not work in 6.5.0-6.5.5 TeamCity versions, see details and workaround in the issue TW-18715.
However, you should really avoid accessing checkout directory of one build from another. If you need sources of A, you can checkout them in B; if you output of the A's build, then publishing the output as build's artifacts and then using TeamCity artifact dependencies is the way to go. In both cases additionally using TeamCity snapshot dependencies will ensure both builds use the same sources snapshot which is probably what you need.
If you have one agent, and only ever one agent then you could try and use the path from a previous build.
I wouldn't recommend doing this however because if you had two agents, or scaled up in the future to two agents, then it is possible your projects will be built on different agents; this would mean your dependency working directory won't be on the same machine, or it will be outdated as the latest was built elsewhere.
I assume you're after the path of the first build to get its output?
If so, the method we use to share dependencies between projects is to checkin the output from each project into our source control, then every project that requires the output simply has to check them out.