I'm trying to get TFS to pass the build number to MSBuild but it looks like the environmental variables are not being parsed and I'm getting the following error:
'$(TF_BUILD_BUILDNUMBER)' is not a valid version string.
The argument I'm using is:
/p:OctoPackPackageVersion=$(TF_BUILD_BUILDNUMBER)
I've also tried using the build id but that doesn't get parsed either. If I type the same version number into the argument then the build completes successfully.
I'm using Visual Studio 2013 and TFS on Visual Studio Online. Please let me know if there any settings I can try change to resolve this.
Thanks very much
That would be correct for the XAML build system. If you're using the newer build system instead, it would be $(Build.BuildNumber).
After many hours I've solved this by changing the build process template to TfvcTemplate.12.xaml.
Old thread I know, but for anyone who has stumbled across this running TFS "15" RC2 or later, using tasks in vNext, the property I found that worked is $(BUILD_BUILDNUMBER) and can be utilised in the .proj files. InstallShield was causing me issues when trying to pass the build number into the ProductVersion...
Adding this line fixed my problem..
<InstallShieldProductVersion>$(BUILD_BUILDNUMBER)</InstallShieldProductVersion>
Related
We recently updated our build servers to using Visual Studio 16.8.1 and Xamarin.iOS 14.4.1.3 and have hit an issue with the previous MSBuild command that used to run.
For the record we are build a Xamarin Forms solution and targeting iOS here.
The command is:
"C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin\msbuild" MySolution.sln /p:Configuration="AppStore" /p:Platform="iPhone" /p:ServerAddress="" /p:ServerUser=""
I have tried searching for the specific error message that it is reporting (below) however I haven't been able to find anything useful so far.
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Xamarin\iOS\Xamarin.Shared.targets(230,3): error MSB4044: The "GetMinimumOSVersion" task was not given a value for the required parameter "SdkVersion".
Update
Upon further digging I believe I have traced the source of the error back to these lines not being set in Xamarin.Shared.props.
<!-- SdkVersion -->
<_SdkVersion Condition="'$(_PlatformName)' == 'macOS'">$(MacOSXSdkVersion)</_SdkVersion>
<_SdkVersion Condition="'$(_PlatformName)' != 'macOS'">$(MtouchSdkVersion)</_SdkVersion>
I haven't been able to find out what sets MtouchSdkVersion and therefore why it isn't being set. A comment from just above the quoted section above states:
Sometimes we've used different variable names for the same thing for Xamarin.iOS and Xamarin.Mac projects. Here we try to unify those variables
Could it be that this unification has changed the behaviour of something that used to work?
This has reared it's head again in Visual Studio 2019 version 16.8.3. Looks like they've moved the problem to:
<VS Install path>\MSBuild\Xamarin\iOS\Xamarin.Messaging.targets I was able to get my builds running again by removing the _SayGoodbye dependency on line 52 for the _DisconnectAfterClean target.
<Target Name="_DisconnectAfterClean" Condition="'$(IsRebuild)' != 'true'" DependsOnTargets="" />
This is certainly not a permanent solution to the problem but a workaround has been supplied by the Xamarin team. For reference the response is on GitHub
we're investigating it, but it looks like the build process is getting disconnected after running the clean targets, so if you run Build instead of Rebuild you shouldn't face this.
In the meantime, a potential workaround to unblock Rebuilds would be to edit <VS Install path>\MSBuild\Xamarin\iOS\Xamarin.iOS.Windows.After.targets and remove the _SayGoodbye entry from the CleanDependsOn property group.
I can confirm that this has allowed our CI builds to operate again.
It should go without saying but I want to make it clear you should backup a copy of the Xamarin.iOS.Windows.After.targets file before doing this.
I've had a problem with my Windows 7 after an update, neither Safe Mode nor Recovery Mode could resolve the problem. I was forced to reinstall Windows completely. To develop on my projects I need Visual Studio 2010.
I always had ReSharper installed and got used to its features, so I installed it aswell.
Everything setup I tried building my solution but encountered a problem ...
(The underlined file can be found here: https://up.zone/aj)
After hours of trying to resolve the problems, I figgured out that ReSharper was the problem. I can build the solution perfectly fine without ReSharper installed. Having it installed, even if all features are turned off and the services are suspended, causes these errors in the picture above to show on build.
I managed to resolve two out of three errors by following the instructions of this Reddit user on his post: https://up.zone/ag
Now I am left with one more exception I cannot figgure out how to resolve. I couldn't really find anything helpful googling, which means you guys are my last hope. I really do not want to go back to developing without ReSharper.
This is the one:
Any idea?
Thank you!
Update 1
I figgured out that the problem must be in the NuGet.targets file, located in the .nuget folder in our solution.
I managed to find a workaround following the suggestion of this post, I am now able to build the solution without any errors.
To summarize, remove this line out of your *.csproj file
<Import Project="$(SolutionDir)\.nuget\nuget.targets" />
Although this works, I don't think this can be the solution. This line is there for a reason I assume. Anybody with a deep understanding of NuGet who might know how to properly resolve this problem?
Update 2
I found out that as soon as you reload your solution/project, the line gets added once again. Also, if you have certain dependencies nuget should download for you - it won't, because the line which makes that call and handles this got removed.
I'm now at a point where I know where the problem is but not why it is caused.
Does ReSharper change anything in the way NuGet behaves? As far as I can tell, nothing gets added or removed to or from the NuGet.targets file due to ReSharper.
There were one more report on this topic, at https://youtrack.jetbrains.com/issue/RSRP-462271 .
The best guess so far is that this is caused by two things happening at once: (a) using MSBuild tasks in C# source code form inside MSBuild XML files rather than DLLs and (b) having some of the MSBuild opensource DLLs shipped with the latest version of ReSharper for its own project file handling needs.
The source code gets compiled into a task DLL during an MSBuild run (not a much common thing to have; Roslyn would do this rather than ship a DLL? seriously?). When building from within Visual Studio (rather than with msbuild.exe), the in-process MSBuild instance is used, and it would run in the same appdomain as ReSharper, so it uses the common assembly reference resoluiton. If it's not too accurate, then it might accidentally pick the wrong DLL version by the short name, which would break the task compilation (that's a separate error, maybe cached away) and then result in the task-not-found error later at runtime (SetEnvironmentVariable task not found in here case).
I've tested on sample solutions with source code based tasks and could not get it broken. So trivial cases are OK. Never heard back from the original issue reporter, so there was no further progress.
Now I've got a hint that this is Visual Studio 10 (any other VS versions installed on that machine?) and maaaaybe it's Roslyn tasks. We might know for sure if you run MSBuild with more detailed logs (by setting the logging options at Tools | Options | Projects and Solutions | Build and Run | MSBuild project build output verbosity to at least Detailed) and building just the faulty project.
I'll also try this out with VS10 and update this reply with new data.
I'm compiling a solution with many projects inside using VS2013's MSBuild. I want the build to stop if one of the projects fails to compile and that the error code of msbuild will be non-zero to indicate something has failed. Can it be done?
I am running this command to start compiling:
%MS_BUILD_PATH% "%workarea%\WindowsSolution.sln" /p:Configuration=Release /p:ContinueOnError=false /p:StopOnFirstFailure=true
but it doesn't work as I want it. Any suggestions?
If anyone is still looking for this feature in Visual Studio, there is a free extension called [VSColorOutput] (here), which has an option to stop the build on first build error. Once you have installed the extension, the options is located at: Tools.Options.VSColorOutput.Build Actions.Stop Build On First Error
The official documentation says StopOnFirstFailure: If true, when one of the projects fails to build, no more projects will be built. Currently this is not supported when building in parallel (with multiple processors).
Can you try setting BuildInParallel=false and see if that helps?
Edit: Found an old blog post that says this might be easy to do if you're building a single .sln with multiple projects http://blogs.msdn.com/b/manishagarwal/archive/2006/05/09/593392.aspx
I'm using StopOnFirstBuildError
https://marketplace.visualstudio.com/items?itemName=EinarEgilsson.StopOnFirstBuildError
It stops the build when the any project building fails. I'm using on 2015. The linked page says it works with Visual Studio 2012, 2013, 2015, 2017.
We are using Visual Studio 2012 and Team Foundation Server 2010 in our project. Since, we are using Microsoft Fakes, we could have not used the started Test functionality of our Team Build 2010, I have created a build activity which invokes VSTest.Console.exe passing the test assemblies. This approach has been working well for us. However, after a recent check-in we are getting the following error when executing Vstest.console.exe
Error: An exception occurred while invoking executor 'executor://mstestadapter/v1': Object reference not set to an instance of an object.
I copied the binary files to my local machine and was able to get the error again. Interestingly, we run a dev build before check-in which runs the same vstest.console.exe with the same parameters and that works correctly. I have got two folders on my machine, for one the call works fine and for other it doesn't. The compiled assemblies look same size and there aren't much differences to suggest.
I tried using Process Monitor but couldn't find anything obvious other than that the process returns with an exit code 1. Does anybody know much about this error? Is there any way I can find out more information from my test run?
Regards,
Hamid
We got to the bottom of the problem. We are using Entity Framework 5.0 and we also have a situation where some of our test assemblies are targeting .Net 4.0 and some are targeting .Net 4.5.
When we are trying to run the tests such that assemblies targeting different versions of .Net framework and using Entity Framework 5.0 are run in the same Test (vstest.console.exe) process, we get this error.
I think this has to do with the way Entity Framework 5.0 ships with two versions (net40 and net45). Once one version of the library is loaded in the process, the other version cannot be loaded and this caused the error.
I had the same error message just now with Visual Studio 2017 using the new MSTest.Framework and MSTest.TestAdapter (to be able to use Live Unit Testing). It turned out I was using multiple versions of those packages in my solution. Consolidating them to the latest version solved the problem.
This is what worked for me:
In Visual Studio, Test -> Test Settings -> Default Processor Architecture -> X64.
Though it might not solve everyone's issue, hope it helps some of you out there.
I have the same error specified in the subject when in the AssemblyInfo of the project is specified the AssemblyAttribute:
[assembly: AssemblyCulture("en")]
If this attribute is present, the run of the unit tests fails.
If I remove this line of code or I remove the en language, the run of the unit tests success.
An exception occurred while invoking executor 'executor://mstestadapter/v2'
I had multiple TestAdapter's and TestFramework's in my BuildAgents Folder, deleting the v1.1.11 versions fixed the issue:
This happened to me recently in VS 2019. Using NuGet to update to the latest versions of MSTest.TestAdapter and MSTest.TestFramework solved the problem for me.
I tried everything on the web to solve this exception. Finally I solved this issue by installing the Update v4 of Visual Studio 2013 (which is that I'm using currently). Hope it helps!
Deleting app.config and packages.config, if exists, and reinstalling Entity framework via nuGet packages works for me.
I'm in the process of upgrading our VS 2008 solution to run on VS 2010
I managed to successfully build in VS 2010
My next step now is to configure a build machine running TFS 2008
Whenever I start a build it does my projects in alphabetical order with no regard for dependencies. I've googled a lot and I can't seem to find a solution to this.
The closest solution to my problem is found here: msdn link which links to this: dependency solution
However I'm dealing with 129 projects, so I would really rather not do this all manually in the xml.
Has anyone been able to effectively remap the dependencies in a way which msbuild recognizes without manipulating the xml for days...?
It turns out that the conversion to VS 2010 makes the build agent have to use the .NET 4.0 version of msbuild.
So I followed the steps outlined here and it worked: Building .NET 4.0 Applications Using Team Build 2008. Keep in mind that those instructions were written during the beta and the path is now v4.0.30319.
This was required even though all my projects are targeting 3.5
Basically I had to make a one line change and now everything is happy (still working on getting my build to pass but the order is good). It had nothing to do with dependencies not being preserved, simply that the way dependencies were being managed wasn't understood by msbuild 3.5
We also have a large number of projects. We wound up (programmatically) creating a MasterSolution.sln file that contained all of the projects. We also require our developers to only use project references in their code. This way, MSBuild always gets the correct order as it parses the .sln file.