I'm trying to get our TFS server to build a solution with an azure project. To get up to speed fast, I installed the azure SDK 1.6 on the build server/agent. I only needs to build and not publish the project for the moment. But I get the error below.
The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Windows Azure Tools\1.6\Microsoft.WindowsAzure.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
Both the development machine and the build agent is x64, but on the development machine the azure stuff was installed in to "programfiles (x86).
Now I really need an advice on how to get the build agent to build the project, do I really need to include some dll's in the project, or how do I best fix this?
Up and running. A quick and dirty installation of the azure sdk and azure tools for visual studio did the trick.
Related
Fairly new to Azure DevOps and PipeLines, but we are stumped by the fact executing an MSBuild command locally or through publish in VS2019 gives us a complete ready to publish folder, while the same command in Azure DevOps pipeline seems to be doing nothing but build.
Local command:
"C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\msbuild" Webshop\Mvc.csproj /p:PublishUrl="c:\Publish\Mvc" /p:DeployOnBuild=true /p:Configuration=Release /p:WebPublishMethod=FileSystem /p:DeployTarget=WebPublish /p:AutoParameterizationWebConfigConnectionStrings=false /p:SolutionDir="." /p:PrecompileBeforePublish=true
MSBuild task:
steps:
- task: MSBuild#1
displayName: 'Build solution'
inputs:
solution: '$/MVC_Projects/<more here>/Webshop/Mvc.csproj'
msbuildVersion: 16.0
platform: '$(BuildPlatform)'
configuration: '$(BuildConfiguration)'
msbuildArguments: '/p:DeployOnBuild=true /p:DeployTarget=WebPublish /p:PublishUrl="$(build.artifactstagingdirectory)\publish" /p:WebPublishMethod=FileSystem /p:AutoParameterizationWebConfigConnectionStrings=false /p:PrecompileBeforePublish=true'
We tried playing with the parameters, but that does not seem to have much effect (or we don't know which parameters to tweek). The most we got was adding an /p:DeployTarget=Package and /p:OutDir="$(build.artifactstagingdirectory)\bin" would copy the bin folder. This was still without the .compiled files we were expecting though.
The project is an ASP.NET MVC Framework 4.8 application. The code does build properly and without errors. The logs do not hint with any warning or tasks not being able to be completed, so no clues there. We require the output folder for the full website and not just the DLL's to make our migration to DevOps easier. Having the folder allows other deployment processes to remain the same.
This might not be best practice, but it is practical for us at this moment in time.
Question 1. Why is MSBuild doing something else locally than in the DevOps Pipeline? Is it perhaps picking up configuration files we are unaware of ?
Question 2. What settings (or perhaps other task) would we need to set up to get the same local publish folder appear in the $(build.artifactstagingdirectory) folder in DevOps ?
Any insight, direction or solution is appreciated.
SOLUTION
After many checks and trials in the build parameters and pipeline setup, it was a DevOps server installation issue. The DevOps server had a full version of 2022 installed and only a partial version of 2019. Although the builds did not give any error or warning, the artifacts were not created without the 'ASP.NET and web components' for Visual Studio 2019 being installed. After that component was installed, the builds ran just fine and as expected.
Lesson learned is to double check local development installation with server installation with relation to installed (individual) components when results vary, even if there are no errors.
I'm new to .net application (non-web application) project and using jenkins for continuous build and release. I completed creating builds for my project and got the .exe and dll files. But i need to repackage it(create a msi) before deploying to servers. So can anyone give a stepwise information for rePackaging and tool to be used with jenkins for packaging. I want to automate this process in jenkins CI AND CD.
Jenkins is not capable to pack any applications directly.
It will always use an external tool via a plugin or installed by you.
In MSI case, you need an windows agent with an app that will receive the command in command line and produce your deliverable.
Applications:
Installshield (very old - paid)
visual studio (paid)
TFS (on premises or cloud) (paid)
MSIX (? I don't know much about it)
WIX (free)
Jenkins plugin here
I have build a UWP application using Sqlite. On my local machine I had to install the following SQLite for Universal Windows Platform Visual Studio Extension to get it to build. I followed this blog when using sqlite on UWP
I am now trying to implement Continuous integration with Visual Studio Team Services (was Team Foundation Server Online).
I am using a Hosted pool to build my application but I get the following message:
C:\Program Files
(x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(2049,5):
error MSB3774: Could not find SDK "SQLite.UWP.2015, Version=3.12.2".
and it breaks the build.
How can I fix this on a hosted pool? I do not have physical access to the machine as this is managed by TFS online
EDIT:
After finding this is a library that is installed on my local machine (through the Visual Studio Extension) and so doesnt exist on my hosted machine meaning the reference is broken I am trying to add the respective files to source control and reference it directly from source control. But I have no idea what dll it is actually referencing as it doesnt say. The properties of the reference are as follows:
Actually there is a simple solution that has worked perfectly for us:
Copy the Microsoft SDKs folder to your repo (or submodule).
Add this to the end of your csproj file:
<PropertyGroup>
<SDKReferenceDirectoryRoot>$(MSBuildProjectDirectory)\..\..\..\..\Microsoft SDKs;$(SDKReferenceDirectoryRoot)</SDKReferenceDirectoryRoot>
</PropertyGroup>
From now on the build process will first check this directory for the required extensions and then fallback to the locally installed extensions. This works perfectly on VSTS hosted agents and doesn't require you to install all the extensions on every dev machine.
There isn't any way to install the extension on Hosted Build Agent.
Q: Does your build depend on software other than this software that is
installed on hosted build resources?
A: No. Then you can use the hosted pool.
Here is the software installed on Hosted Build Agent: Software on the hosted build server.
The work around is deploy your own build agent. With this build agent, you can install the software you want to build your project.
You can not install extra extension in a Hosted VSTS. I tried with TS support and there is no way to do it right now.
You can use difference CI service like Appveyor with give you some control over installing extension via powershell.
Or you can wait for Windows 10 Anniversary with include Sqlite.
Download SQLite for Universal Windows Platform SDK from here
Install it by double clicking.
This solved same issue with my UWP project.
I am trying to get the most basic configuration of TFS 2012 up and running.
So far I installed the TFS server using the simplest option (the 1st option in the installer - the one that comes with a bundled SQL express),
I configured the build service (1 controller, 1 agent, both on the TFS machine).
My project consists of 2 parts: a C#/silverlight part, and a C++ part.
After adding the silverlight prerequisites the C# project builds correctly.
However I can't get the C++ project to build.
I guess I am missing a prerequisite since I am getting the following errors:
C:\Builds\1\proj1\Client\src\Code\Client\proj\main (VC11).vcxproj
(19): The imported project "C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\v110\Microsoft.Cpp.Default.props" was
not found. Confirm that the path in the declaration is
correct, and that the file exists on disk.
Indeed, the TFS server does not have a "C:\Program Files (x86)\MSBuild\Microsoft.Cpp" folder (while my dev machine has one).
I installed the windows SDK, but that didn't help.
I saw on some posts that I need to install VS 2012 on the build machine. Is that correct? will VS express do?
I have been banging my head on this for the last 2 days, and any help would be appreciated.
Installing Visual Studio on your build server seems like a strange thing to do, but having been around the TFS block a bit, I have found it to be the simplest way to manage build servers.
You can copy the files manually from your dev machine to your build server, but if an update to visual studio comes out, you will need to figure out what has changed and make sure you update all those files too. These files typically include Targets files and associated dlls.
Also with all the extensions and packages that are available now, it is just easier to load Visual Studio on your build server and install the required packages than try to work out what is needed to replicate the functionality.
This was made very clear to me recently when Microsoft released ASP.Net and Web Tools 2012.2. This altered the publishing pipeline for Web Sites and Web Projects and I needed to use this in my TFS build. It was so much easier to just be able to log onto my build server, load Visual Studio and download the new update.
I would definitely support installing Visual Studio on your build server.
I have a website, a windows service, and some shared class libraries in a single Visual Studio solution. I use Octopack on both the website and windows service, and on my machine these builds work as expected.
When using the TFS Build Server, the website nuget package is generated as expected, but the windows service nuget package contains all files from the website, as well as the service. E.g. it includes the _PublishedWebsites folder as well.
This is because TFS uses a single location to build projects.
What is the best way around this?
I know this question has since been closed, but I cam across this issue and solved it in a different way.
My solution is compromised of a number of websites and windows services and had the same issue of the OctoPack created nuget packages including all the solution assemblies from the 'pooled' output folder when building with Team Build. The reason the nuget packages get all the assemblies is OctoPack uses the outdir msbuild argument as the location to include assemblies from.
The way I got around it was to use the msbuild argument GenerateProjectSpecificOutputFolder=true. This instructs Team build to create a folder for each project in your output folder in the same way Visual Studio uses the bin folders under each project when building locally.
My build definition msbuild arguments looks like:
/p:GenerateProjectSpecificOutputFolder=true;RunOctoPack=true;OctoPackPublishPackageToFileShare=\\<NugetServer>
I currently just push the packages onto a shared folder but the OctoPackPublishPackageToHttp and OctoPackPublishApiKey parameters can also be used.
The benefit of this solution over the one above is you don't need to specify the files to include the nuget package.
Hope this helps someone.
I ended up using this nuget package to ensure the console app built to a seperate directory on the TFS server.
https://nuget.org/packages/PublishedApplications/2.1.0.0
I then had to specify in the nuspec file, which files should be included for the console app. e.g
This works and I can now deploy using Octopus deploy.
The downside of this apporach is that the PublishedApplications build only works on the TFS build server, so I can't build the project locally in release mode. Still looking on how to overcome this.