I am trying to deploy specific changeset using the SourceVersion variable in the Azure pipeline with no luck. Every time it is anything other than latest build task fails with below error, but works perfectly fine for latest code (no value for SourceVersion):
[error]C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Microsoft\NuGet\16.0\Microsoft.NuGet.targets(186,5):
Error : Your project does not reference ".NETFramework,Version=v4.6.1"
framework. Add a reference to ".NETFramework,Version=v4.6.1" in the
"TargetFrameworks" property of your project file and then re-run NuGet
restore.
I am not sure where to even check for the issue. Really appreciate any input.
Thanks!!
You can try to specify /p:TargetFrameworkVersion=v4.6.1 in the MSBuild Arguments column of the MSBuild task.
MSBuild lets you set properties on the command line by using the -property (or -p) switch. These global property values override property values that are set in the project file. This includes environment properties, but does not include reserved properties, which cannot be changed.
For details ,please refer to this document.
After I updated value for "Clean" under "Get Sources" to "true" and "Clean Option" to "Sources Directory", that did the trick.
Related
I am attempting to set up a DevOps build definition to build a VS2017 solution on an on-site agent.
After adding the standard Visual Studio Build step to the build pipeline, the build agent reports the error:
"Error MSB3030: Could not copy the file "d:\agent_work..."
This seems to be happening for any LINKED item.
These items were added to the project from other solutions ("add existing item->Add As Link")
The solution/project builds fine locally on developers PCs, but not on agent.
All that is really required is for the build step to copy these files to an output directory to be included in the build artifacts.
Properties for all linked items are set to "content & copy always".
Error MSB3030: Could not copy the file "d:\agent_work..." because it was not found.
Am I missing something basic here?
This is a workspace mapping issue. You have files that aren't part of your build workspace. You will need to update your build to have a workspace that is mapped in a fashion equivalent to your developers' workspaces.
If your developers are referencing files outside their workspaces, this is a problem that you will have to rectify, then update the build accordingly.
Solved the build error : "Error MSB3030: Could not copy the file "d:\agent_work..." because it was not found." by adjusting the mappings in preceding "get sources" step. After looking at the logs of the build it appeared that the agent was looking in "d:\agent" for some items and "d:\agent\s" for other items (and not finding them). Don't know why it was looking in the "s" sub-directoy. But anyway, the work-around was to include the "s" in the local path mappings for "Local path under $(build.sourcesDirectory)" (ie: s/MyLocalPath)
I had setup the devops flow for one of my client application. It’s woking fine in build and release level. But after some days suddenly my build failed with the following error.
node_modules\uws\build\binding.sln.metaproj(0,0): Error MSB4126: The specified solution configuration "release|any cpu" is invalid. Please specify a valid solution configuration using the Configuration and Platform properties (e.g. MSBuild.exe Solution.sln /p:Configuration=Debug /p:Platform="Any CPU") or leave those properties blank to use the default solution configuration.
Can anyone please tell me how to resolve this issue?
You can use PowerShell tasks to change the .sln file.
Assume if you want to build projects except a website project, then you can remove the website project info in GlobalSection of the .sln file.
Prerequisites:
Get the project ID you want to remove, the formate as ECF93D95-5096-497E-B4B8-83416DABB516.
Then add a PowerShell task before VS build task which build other projects. The script as:
git checkout $(BUILD.SOURCEBRANCHNAME)
(get-content "$(Build.SourcesDirectory)\relative\path\to\solution") -notmatch "{project_ID}.$(BuildConfiguration)" | out-file "$(Build.SourcesDirectory)\relative\path\to\solution"
Such as below example to remove the project ECF93D95-5096-497E-B4B8-83416DABB516 from .sln file:
git checkout $(BUILD.SOURCEBRANCHNAME)
(get-content "$(Build.SourcesDirectory)\ConsoleAppCore\ConsoleAppCore.sln") -notmatch "{ECF93D95-5096-497E-B4B8-83416DABB516}.$(BuildConfiguration)" | out-file "$(Build.SourcesDirectory)\ConsoleAppCore\ConsoleAppCore.sln"
After the VS Build task, you can add another PowerShell task to recovery the changed .slnas the same version in git repo. The script as:
git reset --hard head
For building websit project except other projects, you can use the same way to skip the project for building.
Note: for PowerShell task, please deselect Fail on Standard Error option.
I think the best option is to use multiple solutions which target group of projects together (Partitioned Solution)
Here is link to get more info about it
Partitioned Solution
Also I implement in many open source project, here one of them
Project on GitHub using Partitioned Solution
I had this problem once while using VSTS. I suggest you to use MSBuild arguments directly
Ho to add to MSBuild Arguments:
/p:Configuration=$(BuildConfiguration) /p:Platform="$(BuildPlatform)"
Note: leave Platform and Configuration empty
I have a Service Fabric project set up with CD in VSTS. The CD process have been set up from the CD wizard in visual studio. So far so good but when the release is made I'm not getting any value from the pre-defined variable called Build.DefinitionName that I use for naming the releases.
This is how my Release name is configured: $(Build.DefinitionName)-$(date:yyyyMM).$(rev:r)
If we look in the release log there is no value for the variables:
[BUILD_DEFINITIONNAME] --> []
[RELEASE_ARTIFACTS_{Primary artifact alias}*_DEFINITIONNAME] --> []
*This value is populated correctly.
And according to the docs of primary artifact variables the two variables above should be the same.
As a result of this my releases are named $(Build.DefinitionName)-201702.7
If I use Build.BuildNumber instead. I get the correct value.
How can I get the variables populated?
Update
When creating the Build and Release definitions manually the $(Build.DefinitionName) gets populated correctly on the Release side. But the problem seems to appear when you use the CD wizard from Visual Studio. I might be missing something but the settings of the Build Definition are identical. Or there is some funky stuff going on with the CD wizard.
The solution is to create the release definition manually on web access and set Continuous Deployment.
On the build number is passed from Build to a release, there is no out of the box way to pass more variables between build and release.
However I write a ser of build tasks to do this: https://marketplace.visualstudio.com/items?itemName=nkdagility.variablehydration
It consists of two tasks, the first saves the specified variables to a json file, which you should put in the build output.
The second restores the variables you want. Especially useful if you have multiple source build for your release.
I use TeamCity as a Build Server and want to pass the revision number from
svn to my msbuild script. The reason is that I want to create a directory on
a test / staging server with this number.
I've googled with bing (and google ;)) but couldn't find a solution.
Any ideas?
As far as I know the build number is already passed to msbuild have you tried the retrive it with:
$(BUILD_NUMBER)
Another option is to use build parameters:
Configuring Build Parameters
From the page above:
.... a convenient way of passing generic or environment-specific settings into the build script.
The build parameters are automaticly append to the msbuild command line, for example:
msbuild.exe test.sln .... /property:foo=bar
The variable %build.vcs.number% contains the svn revision number.
Under command line parameters for an MSBuild runner you can pass this value.
You actually need both of the above answers to achieve what you want. You need to set you teamcity build to use %build.vcs.number% so that when you parameter BUILD_NUMBER is set to that value.
When creating a new build definition in TFS 2010 we specifiy a project or solution to build (Under the 'Required -> Items to Build' section in the 'Process' section of the definition.
Is there any way to get hold of the name of the solution being built in the Workflow scope? I.e. is the there a variable available with this information inside that I can pass into a custom code activity elsewhere within the work flow?
If you open the build workflow and tunnel down into Compile and Test, you'll see a For Each Project loop scope that shows the workflow variable assignment of BuildSettings.ProjectsToBuild as serverBuildProjectItem in an out of the box workflow. There's a task within the sub-sequence that translates that serverItem to a local path containing the proj file.