Does TFS 2013 build supports VS 2012 solutions? - build

I have a solution created in VS2012 recently moved to TFS2013 Express. When I try to define a build in Team Explorer 2013 and select the solution TFS returns following issues:
Parameter 1. Projects: cannot convert value '$/[MY SOLUTION PATH AND NAME].sln' of type Microsoft.TeamFoundation.Build.Workflow.Activities.StringList to type System.String[], reset to default.
Parameter 2. Configurations: cannot convert value 'Microsoft.TeamFoundation.Build.Workflow.Activities.PlatformConfigurationList' of type Microsoft.TeamFoundation.Build.Workflow.Activities.PlatformConfigurationList to type System.String[], reset to default.
When I create a build from VS 2012 - I have problems with setting up automatic tests:
The parameter AutomatedTests could not be loaded because the type InArgument<Microsoft.TeamFoundation.Build.Common.BuildParameter[]> was not found.
The parameter AdvancedTestSettings could not be loaded because the type InArgument<Microsoft.TeamFoundation.Build.Common.BuildParameter> was not found.
The parameter AdvancedBuildSettings could not be loaded because the type InArgument<Microsoft.TeamFoundation.Build.Common.BuildParameter> was not found.
The parameter AgentSettings could not be loaded because the type InArgument<Microsoft.TeamFoundation.Build.Common.BuildParameter> was not found.
The member Microsoft.TeamFoundation.Build.Workflow.ProcessParameterMetadata.ValueFormatString for parameter Metadata could not be loaded because no such member exists.
I'm using TfvsTemplate.12.xaml template

Make sure you are using VS2013 to create your build definitions.

If you get this error when creating a NEW build definition, make sure you select the default Build Controller. Unless the Build Controller is set, the script does not know where the Custom Assemblies resides within TFS.
I wasted half a day figuring that out. Once I selected the default build controller the DLL was loaded and the error/warning went away.

Related

add images to C++/CLI winform project -Visual studio

whenever I try to add images to imagelist or change the form icon i get an error arround here
this->Icon = (cli::safe_cast<System::Drawing::Icon^>(resources->GetObject(L"$this.Icon")));
the error "System.Resources.MissingManifestResourceException: 'Could not find any resources appropriate for the specified culture or the neutral culture. Make sure "CppCLRWinFormsProject.Form1.resources" was correctly embedded or linked into assembly "BoneJsonEditor" at compile time, or that all the satellite assemblies required are loadable and fully signed.' "
any possible way to fix this ?
i used a tamplate called CppCLR_WinForm project to start my project
after looking it up a bit i found that i sould change the build action but i can't find that field in the file properities

Using Environment Variables in a TFS2015 build

I am trying to set up an API-key to be a global variable that is accessible across all of my TFS2015 Builds. Since TFS2015 seems to lack this feature, I am attempting to use a system environment variable on the build server that is then referenced in the build definitions.
According to Microsoft's documentation, this should be possible. So I have set up a system variable (call it APIKey) on the build server and referenced it within the arguments of a build step using the standard syntax (i.e. "ApiKey=$(APIKey)"). However, instead of replacing the variable with the API-key in the system variable it is trying to use $(APIKey) as the value and causing the build to fail.
It also occurred to me that this custom environment variable would instead be set somewhere in the build agent folder itself but, after some poking around, I'm not sure where or how I would do that.
Are either of these things actually doable?
Following are my steps to achieve this:
Create a system variable on build agent machine:
Restart the build agent machine.
Use the variable in build definition. Here I use cmd task as an example and use the $(testvar) as its argument:
The task will read the value from system variable as following:

TFS 2015 builds : Is it possible to use Variables in Repository mappings?

When creating a vNext build on TFS 2015 you can define variables, which are then used in build steps, and can also be used as environment variables in scripts the build runs.
The build I am working on runs scripts that pulls files from mapped locations, so it would be great if I could define a variable and use it in a mapping so that for example, if I update a reference in the project the build is building, I can simply update the variable with the new location and have the repository mappings and scripts all pull correctly from the new location without having to make the change in multiple places.
I have tried doing this by setting up the variable and mapping as follows,
But this generates an error when you try to save the build complaining that there are two '$' characters in the mapping. Is there way to do this or is this not currently possible?
This has been causing me havok for quite a while as well.
For starters, there is a uservoice request for this feature. You can add your votes and input here to get Microsoft to allow this feature: https://visualstudio.uservoice.com/forums/330519-team-services/suggestions/14131002-allow-variables-in-repository-variables-and-trigg
Second, we've developed a workaround that gets us most of the way there. It's not perfect, but it might be useful to you if you're comfortable with the tradeoffs or can work around the deficiencies.
Start by turning off the "Label Sources" option of the build and mapping the Server Path field to you base build. You'll want to add a custom variable to the Build Definition to tell the build instance what TFS location to pull from. For example, we have a base project and then multiple branches from the project, so our source is structured like this
$\Team Project\Project1
$\Team Project\Project1Branch1
$\Team Project\Project1Branch2
$\Team Project\Project1Branch3
and we create a variable named "Branch" that we can set to "Branch1", "Branch2", and so forth.
When we want to build the base project, we leave the Branch variable blank when launching the build. For branch builds, we set it to the name of the branch we want to build.
Then our build steps look like this
Remap Workspace Folder to Branch Folder
Get Files for Specified Branch - We have to do this manually after
remapping our workspace
Compile the Source in the Specified Branch
Publish Build Artifacts from the Specified Branch
Label the Code of the Specified Branch Manually
The Remap task runs the command
tf workfold "$/Team Project/Project1$(Branch)" "$(build.sourcesDirectory)\$(Build.DefinitionName)$(Branch)"
The Manual Get task runs the following command
get /recursive /noprompt "$/Team Project/Project1$(Branch)"
The build uses the Branch variable to point to the correct location of the solution file for the specified branch
$(build.sourcesDirectory)\$(Build.DefinitionName)$(Branch)\SolutionFile.sln
The Publish Artifacts task uses the Branch variable in both the Contents field and the Path field
Example in Contents
**\$(Build.DefinitionName)$(Branch)\bin
The Label Code task uses the following command
tf label "$(build.buildNumber)" "$/Team Project/Project1$(Branch)" /recursive
The downside of this setup is that you don't capture Associated Changes and Work Items to your subsidiary branches as the Server Path field is always set to the main location. This may not be an issue if you always merge from your branches to your main location prior to launching a build meant to go to production. What you can do to compensate for this really depends on your use case.
With some tweaking, you could use this same format to specify full paths as well if you needed to.
It's impossible. Just as the error message mentioned: there are two '$' characters in the mapping. Which means your application's path shouldn't vary from build to build.
Mappings on the Repository page are used to specify source control
folder which contains projects that need to be built in the build
definition. You can set it via clicking the Ellipsis (...) button,
however, you can't include variables in the mapping path.
There is a similar question: Variables in TFS Mappings on Visual Studio Online Team Builds

ClCompile and Emscripten

I had a error with a basic hello world from a set of examples from Emscripten/tests/msvc10
I have a error MSB4096 but i don't find the solution of the problem on visual Studio 2012.
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppBuild.targets(817,5): error MSB4096: The item "..\hello_world.c" in item list "ClCompile" does not define a value for metadata "ProgramDataBaseFileName". In order to use this metadata, either qualify it by specifying %(ClCompile.ProgramDataBaseFileName), or ensure that all items in this list define a value for this metadata.
Do you know the reason?
thanks
When trying to compile keep in mind 2 things:
Do no try to compile managed C++ code with emscripten.
the code is running in browser sandbox
The metadata stuff in your code seems really related to the first issue (managed code).
You have to set the 'Program Database File Name' (ProgramDataBaseFileName) Property in the VS C/C++ Options of your Project e.g. to '$(IntDir)$(TargetName).pdb'
ProgramDataBaseFileName exposes the functionality of the compiler's /Fd (Program Database File Name) option.
MSDN ProgramDataBaseFileName

CPP unit build error in VS 2010

I am builidng CPPunit 1.12.1 using VS 2010. I able to build CPP unit successfully on VS 2008. I am building only CPPUnit library.
I am getting following error. How can i fix this error.
error MSB3073: The command "copy "D:\src\cppunit\.\Debug\cppunit.lib" ..\..\lib\cppunit.lib
:VCEnd" exited with code 1. C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets 113 6 cppunit
I am also mentioning one of warnings which is related to error i think so.
C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(1151,5): warning MSB8012: TargetPath(D:\src\cppunit\.\Debug\cppunit.lib) does not match the Library's OutputFile property value (D:\src\cppunit\Debug\cppunitd.lib). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Lib.OutputFile).
These are post-build event errors.
Right click on your project-name in Visual Studio Solution Explorer:
Properties >> Post-Build Event
Remove the text from CommandLine textbox if you don't want post-build events. Or fix the path!
The issue is that the post-build step is something like: copy "$(TargetPath)" ....\lib\$(TargetName).lib.
Since the 'TargetName' value changes depending upon the build type, go in the project properties and change the 'target name' depending upon the selected build. In your case, if you check your 'warning' carefully, you will find that you are trying to copy the cppunit.lib to the ..\lib folder when actually your expected output is supposed to be cppunitd.lib. TargetName mismatch!
Another thing that I found helpful (it may be something only I observed) was building the 'release' build first, followed by the 'debug' build.
You have the configuration slightly messed up.
You are telling MSVC to create an output file in one directory and then use it from a different one - and it looks like at least one of the dirs doesn't exist.
It's nothign to do with cppunit