I am getting this error when using VisualStudio.com to build my solution:
C:\a\src\...\Setup\Setup.isproj (30): The imported project "C:\Program Files (x86)\MSBuild\InstallShield\2013Limited\InstallShield.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
One of the projects in my solution is an InstallShield installer project. Am I supposed to remove it? Or is there a way to make it work with TFS Build on the cloud?
InstallShield is not installed on the Hosted Build Services, so you'll have to disable the project for VSO. You don't have to remove it, it's enough to create a new build configuration and untick the "build" option. Then configure the Build to use the "BuildServer|AnyCpu" configuration to build.
If you want to build your project including the installer, you'll need to install your own build agent/controller and install InstallShield on that. Either on an Azure VM or on an on-premise
Related
Background
I recently converted my Xamarin.Forms app from PCL to Net Standard format.
All of my projects now use PackageReference in the csproj file. Which means no more package.config or package.json.
We use TFS 2015 to build, sign, package our .ipa and .apk files. After conversion, the default MSBUILD build steps do not work as they look for mdtool and the new Visual Studio has vstool instead. So, I updated the build steps to use new tools via command line.
All my projects are NetStandard now (including iOS and Android).
Issue
I can successfully restore NuGet packages using restore MySolution.sln -force on Mac build server. But when I run vstool build MySolution.sln after that, I get this error:
error: NuGet packages need to be restored before building. NuGet
MSBuild targets are missing and are needed for building. The NuGet
MSBuild targets are generated when the NuGet packages are restored.
I am able to successfully run the nuget restore and vstool build locally on the build machine. But only when TFS runs the command via agent, it shows that error message.
Setup
Builds: TFS 2015 on Mac agent running Visual Studio 7.5
According to the error and your description, you need also check if your build agent has corresponding capability to support vsbuild.
Take a look at this related question MacOS - Visual Studio Support and give a try with this workaround:
As a work around we set the Xamarin.iOS variable manually in the build
agent and changed the mdtool path in the Xamarin iOS Build step to
"/Applications/Visual Studio.app/Contents/MacOS/vstool".
Besides you could also try to use the suggestion from Matt in the comment above.
Ok. I was finally able to get a successful iOS build on Mac server. This is the setup that works,
Using PackageReference in iOS .csproj
No package.config, project.json, or AssemblyInfo.cs file.
Running nuget restore .sln before building the iOS project.
Build solution using <path-to-vstool>\vstool build .sln -c:<configuration>
Now, I am working on the Windows machine for Android setup. Once I have that working, I will post my findings here.
I want to modernize my workflow of how I deal with client libraries (js, css, etc.) that I get via NPM or Bower.
I don't want to check client libraries into TFS source control.
When another developer downloads the project, their local Visual Studio and NPM/Bower will restore the libs to their workstation. And of course they would not be able to check in to TFS any client library either. Gotta keep Source Code repo clean.
When I do a local build, the local build will bundle and minify what I have locally.
When I check in my code and do a build at TFS, it would handle doing a NPM or Bower Restore there, and ALSO handle bundling and minification there.
Is that possible in the Visual Studio/TFS ecosystem?
I guess the same question can be asked of Nuget packages for server side things.
I imagine that I will have to do something with tfignore, and also somehow use a special build task (or PowerShell script) at TFS during build.
Is this overkill, or is this actually a normal, standard best practice?
Edit: versions I am using.
VS2015 Enterprise
TFS and TFS Build (on prem) 2015
In your local machine:
You need to create a NPM package.json file for your project. And when you install NPM packages, add "--save" parameter. "NPM install packageName --save".
Don't add those client libraries/packages to TFS source control. If you already added, you could delete them from TFS. Or use .tfignore file to avoid them from being checked in.
In TFS build definition:
Add a NPM build task and use this task to install those libraries when building on the build agent.In the step, you'd better specify a "Working Directory", the path is where your package.json file located. When this step runs, it will find the package.json file in the "Working Directory" and install those libraries defined in the package.json file.
My MSBuild proj file is referencing Microsoft.Web.Publishing.targets. Even though microsoft says MSBuild is standalone installation, i dont think this file is part of MSBuild.
I am trying to setup a build server. and i don't see this file at this location. We have installed .Net 4.5.2 installed on that server.
C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\vXX.X\Web\Microsoft.Web.Publishing.targets
After researching I found, I have to install VisualStudio to get this at that location.
Questions
Is there any way to install this Target (and other Targets at this location) without having to install visual studio?
Yes, you can use the MSBuild.Microsoft.VisualStudio.Web.targets package.
I updated to VS2015 this week and along with that updated all NuGet packages in my website solution.
The site builds and run fine locally, however when doing my gated check in to my build server, I get the following when the build fails
As you can see the packages are complaining about the NuGet version, but I'm unsure how to update the NuGet version on the build server. I do have admin privileges to the server, but following the guild described at: http://blog.stangroome.com/2014/02/04/update-nuget-exe-version-used-by-team-build-2013-package-restore/ did not help. For one, my folder was actually C:\Program Files\Microsoft Team Foundation Server 11.0\Tools unlike the C:\Program Files\Microsoft Team Foundation Server 12.0\Tools described in the guide, but additionally I did not have a NuGet.exe within the folder.
I've done a full hard drive search of NuGet.exe, but could not locate it in any directories aside from the directories that are directly related to project source code (.nuget\NuGet.exe).
I have opened visual studio on the server and updated the NuGet version within "Extension and Updates" hoping that would fix the issue, unfortunately it did not.
Any ideas on how to fix the issue/errors presented in the screenshot?
The problem is that you're using the old-style, deprecated-since-NuGet 2.7-style "package restore" that's based on modifying your CSProj files to include references to a NuGet.targets file and a copy of NuGet.exe that gets put into a .nuget folder and ends up source controlled.
Basically, the version of nuget.exe that's on the build server is irrelevant right now -- your CSProj files are pointing to the file in your .nuget folder.
TFS 2013 and beyond has support for automatic package restore without using the NuGet.targets method. You can migrate off of it pretty easily: https://docs.nuget.org/consume/package-restore/migrating-to-automatic-package-restore
My issue is "When I build a project on my build server, it does not get the correct version. But when I build it locally the project locally it does get the correct version"
How do I know this? ...On the build server when I open the file, the contents are not what they should be, as they are in TFS.
I am using Visual Studio 2013 and WIX 3.8. On my build servers I have wix 3.8.
I have a WIX installer (INSTALLER XYZ) which references project A.
Project A has a configuration.config file inside it. The configuration.config file is essential for the MSI to work. When I build the "installer XYZ" locally and install it everything works fine.
When I run a build (on the build server) it builds "installer XYZ" and produces a .msi file. When I install the .msi file I get an error. The install fails.
After investigating and I have found out that when I build on the build server, the "installer XYZ" which references Project A configuration.config file is using an older version of this file and not the latest version. I don't understand why this is happening.
If I use the .msi which was built locally, it installs fine but when I use the .msi which was built on the build server, it does not install.
Let me explain a few things that I have tried...
The msi's are exactly the same except for this configuration.config file. I have used the tools LessMsi and Orca to examine the .msi's.
When I build the project on the build server, I have checked the configuration.config file and it is different the one in Project A
I have got the latest from TFS before building. I have got specific and overwritten all the files from TFS before building.
I have expanded project A and right clicked on configuration.config file and selected properties. The property "COPY TO OUTPUT DIRECTORY" is set to COPY ALWAYS".
My WIX installer is harvesting the files correctly. I have recreated my .WXS file and referenced project A correctly using Source="$(var.Connectors.AgentService.TargetDir)"
On my build server I have deleted all workspaces.
I have deleted all work spaces that my build service account created.
My build definition "Clean Workspace" is set to "All"
I have restarted my computer and the build server
To conclude, I know what the issue is but I'm not sure what's causing it... Can anybody advise?
Update 22.05.2014
So I've investigated further,
I have another project in the same solution called Project.B
Project.B also has a configuration.config file.
What seems to be happening is that the configuration.config file from Project B is being built. I tested this by changing the contents of project.B configuration.config file and rebuilding it. However, my WIX installer references project A configuration.config file.
It seems that the build process is getting confused between the two projects in the same solution.
Does anybody know why this could be happening?
In TFS build, all files are copied into one bin folder. However, Visual Studio has "bin folder per project" structure.
This would explain why your configuration.config is overridden by projectB. They are all copied into same folder.
You can split the folder structure again, by adding this property to your build definition:
Notice the flag /p:GenerateProjectSpecificOutputFolder=true