I am creating a new solution under Visual Studio 2017 Community Edition, it's mainly a .net core web application.
It works perfectly, no problem at all, but we want to deploy it to a Debian machine and to be self contained, so we added the runtime identifiers to the project. So far so good, the problem comes when we want to publish the application (to a directory) for any of the platforms we have, there is no option to specify the target platform and the publish files created are just the .net assemblies, no native modules.
Of course if we use dotnet publish -r (platform) it works as expected, it creates the correct platform files and everything seems to be ok, but is very annoying to have to go to command line to compile it.
So the question is, how can be published a self-contained application for a concrete platform using Visual Studio 2017? Is it even possible or this is still missing?
Currently VS2017 won't do this so you have to drop to the command line and run this.
dotnet publish -c release -r ubuntu.14.04-x64
Obviously replacing ubuntu for your debian flavour.
Also this is in my csproj file and you might need it too.
<OutputType>Exe</OutputType>
You can update your project file csproj to add runtimeIdentifier:
<RuntimeIdentifier>win7-x86</RuntimeIdentifier>
replace win7-x86 with your desired runtime.
Even though in the publish screen it says Runtime: Portable, it does seem to generate a stand alone version.
Result in explorer:
Executed command by vs2017
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Roslyn\csc.exe /noconfig /unsafe- /checked- /nowarn:1701,1702,1705,2008 /nostdlib+ /platform:x86 /errorreport:prompt /warn:4 /define:TRACE;RELEASE;NETCOREAPP1_1 /errorendlocation /preferreduilang:en-US /reference:C:\Users\Joel\.nuget\packages\microsoft.csharp\4.3.0\ref\netstandard1.0\Microsoft.CSharp.dll /reference:C:\Users\Joel\.nuget\packages\microsoft.visualbasic\10.1.0\ref\netstandard1.1\Microsoft.VisualBasic.dll /reference:C:\Users\Joel\.nuget\packages\microsoft.win32.primitives\4.3.0\ref\netstandard1.3\Microsoft.Win32.Primitives.dll /reference:C:\Users\Joel\.nuget\packages\system.appcontext\4.3.0\ref\netstandard1.6\System.AppContext.dll /reference:C:\Users\Joel\.nuget\packages\system.buffers\4.3.0\lib\netstandard1.1\System.Buffers.dll /reference:C:\Users\Joel\.nuget\packages\system.collections.concurrent\4.3.0\ref\netstandard1.3\System.Collections.Concurrent.dll /reference:C:\Users\Joel\.nuget\packages\system.collections\4.3.0\ref\netstandard1.3\System.Collections.dll /reference:C:\Users\Joel\.nuget\packages\system.collections.immutable\1.3.0\lib\netstandard1.0\System.Collections.Immutable.dll /reference:C:\Users\Joel\.nuget\packages\system.componentmodel.annotations\4.3.0\ref\netstandard1.4\System.ComponentModel.Annotations.dll /reference:C:\Users\Joel\.nuget\packages\system.componentmodel\4.3.0\ref\netstandard1.0\System.ComponentModel.dll /reference:C:\Users\Joel\.nuget\packages\system.console\4.3.0\ref\netstandard1.3\System.Console.dll /reference:C:\Users\Joel\.nuget\packages\system.diagnostics.debug\4.3.0\ref\netstandard1.3\System.Diagnostics.Debug.dll /reference:C:\Users\Joel\.nuget\packages\system.diagnostics.diagnosticsource\4.3.0\lib\netstandard1.3\System.Diagnostics.DiagnosticSource.dll /reference:C:\Users\Joel\.nuget\packages\system.diagnostics.process\4.3.0\ref\netstandard1.4\System.Diagnostics.Process.dll /reference:C:\Users\Joel\.nuget\packages\system.diagnostics.tools\4.3.0\ref\netstandard1.0\System.Diagnostics.Tools.dll /reference:C:\Users\Joel\.nuget\packages\system.diagnostics.tracing\4.3.0\ref\netstandard1.5\System.Diagnostics.Tracing.dll /reference:C:\Users\Joel\.nuget\packages\system.dynamic.runtime\4.3.0\ref\netstandard1.3\System.Dynamic.Runtime.dll /reference:C:\Users\Joel\.nuget\packages\system.globalization.calendars\4.3.0\ref\netstandard1.3\System.Globalization.Calendars.dll /reference:C:\Users\Joel\.nuget\packages\system.globalization\4.3.0\ref\netstandard1.3\System.Globalization.dll /reference:C:\Users\Joel\.nuget\packages\system.globalization.extensions\4.3.0\ref\netstandard1.3\System.Globalization.Extensions.dll /reference:C:\Users\Joel\.nuget\packages\system.io.compression\4.3.0\ref\netstandard1.3\System.IO.Compression.dll /reference:C:\Users\Joel\.nuget\packages\system.io.compression.zipfile\4.3.0\ref\netstandard1.3\System.IO.Compression.ZipFile.dll /reference:C:\Users\Joel\.nuget\packages\system.io\4.3.0\ref\netstandard1.5\System.IO.dll /reference:C:\Users\Joel\.nuget\packages\system.io.filesystem\4.3.0\ref\netstandard1.3\System.IO.FileSystem.dll /reference:C:\Users\Joel\.nuget\packages\system.io.filesystem.primitives\4.3.0\ref\netstandard1.3\System.IO.FileSystem.Primitives.dll /reference:C:\Users\Joel\.nuget\packages\system.io.filesystem.watcher\4.3.0\ref\netstandard1.3\System.IO.FileSystem.Watcher.dll /reference:C:\Users\Joel\.nuget\packages\system.io.memorymappedfiles\4.3.0\ref\netstandard1.3\System.IO.MemoryMappedFiles.dll /reference:C:\Users\Joel\.nuget\packages\system.io.unmanagedmemorystream\4.3.0\ref\netstandard1.3\System.IO.UnmanagedMemoryStream.dll /reference:C:\Users\Joel\.nuget\packages\system.linq\4.3.0\ref\netstandard1.6\System.Linq.dll /reference:C:\Users\Joel\.nuget\packages\system.linq.expressions\4.3.0\ref\netstandard1.6\System.Linq.Expressions.dll /reference:C:\Users\Joel\.nuget\packages\system.linq.parallel\4.3.0\ref\netstandard1.1\System.Linq.Parallel.dll /reference:C:\Users\Joel\.nuget\packages\system.linq.queryable\4.3.0\ref\netstandard1.0\System.Linq.Queryable.dll /reference:C:\Users\Joel\.nuget\packages\system.net.http\4.3.0\ref\netstandard1.3\System.Net.Http.dll /reference:C:\Users\Joel\.nuget\packages\system.net.nameresolution\4.3.0\ref\netstandard1.3\System.Net.NameResolution.dll /reference:C:\Users\Joel\.nuget\packages\system.net.primitives\4.3.0\ref\netstandard1.3\System.Net.Primitives.dll /reference:C:\Users\Joel\.nuget\packages\system.net.requests\4.3.0\ref\netstandard1.3\System.Net.Requests.dll /reference:C:\Users\Joel\.nuget\packages\system.net.security\4.3.0\ref\netstandard1.3\System.Net.Security.dll /reference:C:\Users\Joel\.nuget\packages\system.net.sockets\4.3.0\ref\netstandard1.3\System.Net.Sockets.dll /reference:C:\Users\Joel\.nuget\packages\system.net.webheadercollection\4.3.0\ref\netstandard1.3\System.Net.WebHeaderCollection.dll /reference:C:\Users\Joel\.nuget\packages\system.numerics.vectors\4.3.0\ref\netstandard1.0\System.Numerics.Vectors.dll /reference:C:\Users\Joel\.nuget\packages\system.objectmodel\4.3.0\ref\netstandard1.3\System.ObjectModel.dll /reference:C:\Users\Joel\.nuget\packages\system.reflection.dispatchproxy\4.3.0\ref\netstandard1.3\System.Reflection.DispatchProxy.dll /reference:C:\Users\Joel\.nuget\packages\system.reflection\4.3.0\ref\netstandard1.5\System.Reflection.dll /reference:C:\Users\Joel\.nuget\packages\system.reflection.extensions\4.3.0\ref\netstandard1.0\System.Reflection.Extensions.dll /reference:C:\Users\Joel\.nuget\packages\system.reflection.metadata\1.4.1\lib\netstandard1.1\System.Reflection.Metadata.dll /reference:C:\Users\Joel\.nuget\packages\system.reflection.primitives\4.3.0\ref\netstandard1.0\System.Reflection.Primitives.dll /reference:C:\Users\Joel\.nuget\packages\system.reflection.typeextensions\4.3.0\ref\netstandard1.5\System.Reflection.TypeExtensions.dll /reference:C:\Users\Joel\.nuget\packages\system.resources.reader\4.3.0\lib\netstandard1.0\System.Resources.Reader.dll /reference:C:\Users\Joel\.nuget\packages\system.resources.resourcemanager\4.3.0\ref\netstandard1.0\System.Resources.ResourceManager.dll /reference:C:\Users\Joel\.nuget\packages\system.runtime\4.3.0\ref\netstandard1.5\System.Runtime.dll /reference:C:\Users\Joel\.nuget\packages\system.runtime.extensions\4.3.0\ref\netstandard1.5\System.Runtime.Extensions.dll /reference:C:\Users\Joel\.nuget\packages\system.runtime.handles\4.3.0\ref\netstandard1.3\System.Runtime.Handles.dll /reference:C:\Users\Joel\.nuget\packages\system.runtime.interopservices\4.3.0\ref\netcoreapp1.1\System.Runtime.InteropServices.dll /reference:C:\Users\Joel\.nuget\packages\system.runtime.interopservices.runtimeinformation\4.3.0\ref\netstandard1.1\System.Runtime.InteropServices.RuntimeInformation.dll /reference:C:\Users\Joel\.nuget\packages\system.runtime.numerics\4.3.0\ref\netstandard1.1\System.Runtime.Numerics.dll /reference:C:\Users\Joel\.nuget\packages\system.security.cryptography.algorithms\4.3.0\ref\netstandard1.6\System.Security.Cryptography.Algorithms.dll /reference:C:\Users\Joel\.nuget\packages\system.security.cryptography.encoding\4.3.0\ref\netstandard1.3\System.Security.Cryptography.Encoding.dll /reference:C:\Users\Joel\.nuget\packages\system.security.cryptography.primitives\4.3.0\ref\netstandard1.3\System.Security.Cryptography.Primitives.dll /reference:C:\Users\Joel\.nuget\packages\system.security.cryptography.x509certificates\4.3.0\ref\netstandard1.4\System.Security.Cryptography.X509Certificates.dll /reference:C:\Users\Joel\.nuget\packages\system.security.principal\4.3.0\ref\netstandard1.0\System.Security.Principal.dll /reference:C:\Users\Joel\.nuget\packages\system.text.encoding\4.3.0\ref\netstandard1.3\System.Text.Encoding.dll /reference:C:\Users\Joel\.nuget\packages\system.text.encoding.extensions\4.3.0\ref\netstandard1.3\System.Text.Encoding.Extensions.dll /reference:C:\Users\Joel\.nuget\packages\system.text.regularexpressions\4.3.0\ref\netcoreapp1.1\System.Text.RegularExpressions.dll /reference:C:\Users\Joel\.nuget\packages\system.threading\4.3.0\ref\netstandard1.3\System.Threading.dll /reference:C:\Users\Joel\.nuget\packages\system.threading.tasks.dataflow\4.7.0\lib\netstandard1.1\System.Threading.Tasks.Dataflow.dll /reference:C:\Users\Joel\.nuget\packages\system.threading.tasks\4.3.0\ref\netstandard1.3\System.Threading.Tasks.dll /reference:C:\Users\Joel\.nuget\packages\system.threading.tasks.extensions\4.3.0\lib\netstandard1.0\System.Threading.Tasks.Extensions.dll /reference:C:\Users\Joel\.nuget\packages\system.threading.tasks.parallel\4.3.0\ref\netstandard1.1\System.Threading.Tasks.Parallel.dll /reference:C:\Users\Joel\.nuget\packages\system.threading.thread\4.3.0\ref\netstandard1.3\System.Threading.Thread.dll /reference:C:\Users\Joel\.nuget\packages\system.threading.threadpool\4.3.0\ref\netstandard1.3\System.Threading.ThreadPool.dll /reference:C:\Users\Joel\.nuget\packages\system.threading.timer\4.3.0\ref\netstandard1.2\System.Threading.Timer.dll /reference:C:\Users\Joel\.nuget\packages\system.xml.readerwriter\4.3.0\ref\netstandard1.3\System.Xml.ReaderWriter.dll /reference:C:\Users\Joel\.nuget\packages\system.xml.xdocument\4.3.0\ref\netstandard1.3\System.Xml.XDocument.dll /debug- /debug:portable /filealign:512 /nologo /optimize+ /out:obj\Release\netcoreapp1.1\win7-x86\ConsoleApp1.dll /ruleset:"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Team Tools\Static Analysis Tools\\Rule Sets\MinimumRecommendedRules.ruleset" /target:exe /warnaserror- /utf8output /deterministic+ /analyzer:C:\Users\Joel\.nuget\packages\microsoft.codeanalysis.analyzers\1.1.0\analyzers\dotnet\cs\Microsoft.CodeAnalysis.Analyzers.dll /analyzer:C:\Users\Joel\.nuget\packages\microsoft.codeanalysis.analyzers\1.1.0\analyzers\dotnet\cs\Microsoft.CodeAnalysis.CSharp.Analyzers.dll Program.cs "C:\Users\Joel\AppData\Local\Temp\.NETCoreApp,Version=v1.1.AssemblyAttributes.cs" obj\Release\netcoreapp1.1\win7-x86\\TemporaryGeneratedFile_E7A71F73-0F8D-4B9B-B56E-8E70B10BC5D3.cs obj\Release\netcoreapp1.1\win7-x86\\TemporaryGeneratedFile_036C0B5B-1481-4323-8D20-8F5ADCB23D92.cs obj\Release\netcoreapp1.1\win7-x86\\TemporaryGeneratedFile_5937a670-0e60-4077-877b-f7221da3dda1.cs obj\Release\netcoreapp1.1\win7-x86\ConsoleApp1.AssemblyInfo.cs
Related
I am setting up a new TeamCity build agent. Several build configurations that run perfectly well on the existing agent are failing on the new agent, with errors like this (whitespace added for clarity):
[22:14:32][someproject.vbproj]
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\bin\Microsoft.VisualBasic.CurrentVersion.targets(322, 5):
error MSB4019: The imported project
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\bin\Roslyn\Microsoft.VisualBasic.Core.targets"
was not found.
Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
Note the path on line three after "The imported project". The error is correct; the folder does exist but the file does not exist there. However the Microsoft.VisualBasic.Core.targets file does exist at a slightly different path
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\Roslyn\Microsoft.VisualBasic.Core.targets
Is there an easy fix for this, perhaps a registry entry telling MSBuild where to look?
Cause
On your machine, there are two copies of VS 2017 installed, Professional edition and the raw Build Tools.
You didn't install VB bits for Professional, while did that for Build Tools.
TeamCity prefers MSBuild from Professional edition.
Combine all above, the issue happened.
Fix
You should either force TeamCity to use MSBuild from Build Tools, or add VB to your VS Pro installation.
Reference
https://blog.lextudio.com/the-rough-history-of-msbuild-cc72a217fa98
I can't build a vs2017 solution from the command line, but I can build from the IDE. Once I've built from the IDE the command line build will work. So the ide is doing something different - what am I missing? Here is what I do for the command line build:
nuget.exe restore mysoln.sln
"E:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\msbuild.exe" /m /t:Rebuild /clp:Summary /p:Configuration=Debug /p:Platform="Any CPU" mysoln.sln
The output I get:
"Forms.csproj" (Clean target) (14:3) ->
E:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.TargetFrameworkInference.targets(126,5): error : The current .NET SDK does not support targeting .NET Standard 2.0. Either target .NET Standard 1.6 or lower, or use a version of the .NET SDK that supports .NET Standard 2.0. [E:\wp\Forms.csproj]
Any ideas how I can make the command line build work?
==============
Update
I tried "E:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\msbuild.exe" /m /t:Restore GpsConsole.sln from the command line and it works. But when jenkins runs the exact same command i get the same error
==============
Update 2
The way we got the solution building was :
nuget.exe restore mysoln.sln
"E:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\msbuild.exe" /m /t:Restore mysoln.sln
"E:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\msbuild.exe" /m /t:Rebuild /clp:Summary /p:Configuration=Debug /p:Platform="Any CPU" mysoln.sln
I suggest you rethink you command-line approach.
You can make your build script independent of Visual Studio installation, make it using MSBuild version you want, and reusable on a build server.
Short plan
Install Visual Studio Build Tools 2017
Find proper MSBuild
Clean solution
Restore packages
Build solution
Details
Using Build Tools will give you independence from Visual Studio installation.
Download Build Tools for Visual Studio 2017 from Visual Studio Downloads page (direct link)
Command-line arguments documented here: Use command-line parameters to install Visual Studio 2017
All workloads and components are listed here: Visual Studio Build Tools 2017 component directory
You can use PowerShell module VSSetup. Download it or install from here: Github: Microsoft/Visual Studio Setup PowerShell Module
Just run MSBulid with clean target
Help nuget.exe to use proper MSBuild
Run MSBuild with build target (you can add additional required parameters)
# 1. Find MS Build
Import-Module $PSScriptRoot\VSSetup\VSSetup.psd1
$msBuildPath = (Get-VSSetupInstance | Select-VSSetupInstance -Version 15.0 -Product Microsoft.VisualStudio.Product.BuildTools).InstallationPath
if ([System.IntPtr]::Size -eq 8)
{
$global:msbuildPath = Join-Path $msBuildPath 'MSBuild\15.0\Bin\amd64'
}
else
{
$global:msbuildPath = Join-Path $msBuildPath 'MSBuild\15.0\Bin'
}
Write-Output "Using MSBuild from $global:msbuildPath"
Write-Output "MSBuild /version"
$msbuild = Join-Path $global:msbuildPath msbuild
& $msbuild /version
# 2. Clean
& $msbuild "$sln_file" /t:Clean /v:q /nologo
# 3. Restore
$nuget = Join-Path $PSScriptRoot "\.nuget\nuget.exe"
& $nuget restore -MSBuildPath $global:msbuildPath
# 4. Build
& $msbuild "$sln_file" /t:Build /v:q /nologo
I believe your visual studio does have the .net core 2.0 SDK installed, since it is able to build your .net standard 2.0 solution.
But, nuget restore is pointing to an sdk inside the visual studio directory (one of a few that visual studio can use, but not where .net core 2.0 sdk installs to by default).
Your .net core 2.0 sdk is likely located in C:\...\dotnet\...
You'll want to have nuget restore use the msbuild located inside that directory, rather than the one within the visual studio directory.
I have a VS 2013 console application that loads any solution(.sln) file - compiles all projects within it using Roslyn and extracts API usage information from the compilation model.
I am now facing this peculiar issue - When I run the application from within Visual Studio 2013 (using Ctrl-F5 or F5) everything works fine. I am able to compile stuff and extract all information.
However when I open a command line (cmd) and try to run this Console app from I get the following error:
Unhandled Exception: System.AggregateException: One or more errors occurred. ---> Microsoft.Build.Exceptions.InvalidProjectFileException: The imported project "
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the <Impor
When I run
Note the v14.0 there. Why does MSBuildWorkspace try to look into v14.0 directory for required target files ? Is it because I installed the MSBuild tools for CTP and the default path while I run stuff from a simple command line has changed ?
--Edit--
Here is the import
<Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
However I doubt it is to do with the Import statement as such. If I run the console app .exe from the "Developer Command Prompt for Visual Studio 2013" everything works fine again.
You can make your Web Application projects self-contained and not require Visual Studio 2015 to compile by adding NuGet reference to MSBuild.Microsoft.VisualStudio.Web.targets.
I had this problem on my build server. When I targeted /tv:14.0 (Tool Version 14.0 which is the Roslyn Build engine)
I resolved it by going out to C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio then creating folders like v14.0\WebApplications
I then went out to my system with Microsoft.WebApplication.targets (because this is put out there by Visual Studio 2015) and copied that file out to the build servers new folder.
I am trying to use MSDeploy to deploy an MVC project to the server using TeamCity. When I do this on my computer in powershell, using the following command:
msbuild.exe .\mvc.csproj /p:PublishProfile=DevServer /p:VisualStudioVersion=11.0
/p:DeployOnBuild=True /p:Password=MyPassword /p:AllowUntrustedCertificate=true
It builds the project and deploys it to the server (info defined in the DevServer publish profile) perfectly. The output shows an MSDeployPublish section at the end, in which I see text like Starting Web deployment task from source... and then with rows telling me what files are updated, etc.
When I run this on TeamCity, using an MSBuild Build step, on the same file, with the same parameters (from the same working directory) it builds the project but does not publish it. Instead it has the regular output from a build process (CoreCompile, _CopyFilesMarkedCopyLocal, GetCopyToOutputDirectoryItems, CopyFilesToOutputDirectory) but then does not actually go and publish anything.
What changes to I need to make to the setup in TeamCity to get it to publish deploy in the same way that it works using MSBuild from my computer?
(TeamCity 7.1, MSBuild 4.0, WebDeploy 3.0, Visual Studio 12, IIS 7. Related to my previous question)
We do our WebDeploys with a TeamCity MSBuild step configured as follows:
Build File Path: Server.csproj
Command Line Parameters:
/p:Configuration=%configuration%
/p:DeployOnBuild=True
/p:DeployTarget=MSDeployPublish
/p:MsDeployServiceUrl=https://%web.deploy.server%:8172/MsDeploy.axd
/p:DeployIisAppPath=%web.deploy.site%
/p:AllowUntrustedCertificate=True
/p:Username=
/p:AuthType=NTLM
We use integrated authentication; change as necessary to fit your scheme. The value of this, I think, is that it builds everything from scratch and doesn't rely on a pre-built package. From the gist you posted I noticed that you do some DB publishing, we don't use WebDeploy for that so I can't offer any guidance there. Hope this helps.
I use MSBuild.exe to package to zip, and MSdeploy.exe to deploy in separate steps.
To deploy the package.zip file on the command line:
"C:\Program Files\IIS\Microsoft Web Deploy V2\msdeploy.exe" -verb:sync
-source:package="C:\Build\MyAppName.Debug.zip"
-dest:auto,wmsvc=webservername,username=webdeploy,password=*******
-allowUntrusted=true
This command is also worth explaining in detail:
-verb:sync : makes the web site sync from the source to the destination
-source:package="C:\Build\MyAppName.Debug.zip" : source is an MSBuild zip file package
-dest:auto,wmsvc=webservername : use the settings in the package file to deploy to the server. The user account is an OS-level account with permission. The hostname is specified, but not the IIS web site name (which is previously specified in the MSBuild project file in the project properties).
You can modify parameters based on your configuration. I like it this way because with separate steps, its easier to debug problems.
Use TeamCity build step and the command line runner.
Update:
If you want an example of how to build the ZIP package using MSBuild, try something like this:
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe"
MyWebApp/MyWebApp/MyWebApp.csproj
/T:Package
/P:Configuration=Debug;PackageLocation="C:\Build\MyWebApp.Debug.zip"
This should work the same on your local PC as well as on the CI server.
Here are the config settings that finally worked for me:
/p:Configuration=CONFIG-NAME
/p:DeployOnBuild=True
/p:DeployTarget=MSDeployPublish
/p:MsDeployServiceUrl=http://SITE-URL/MsDeployAgentService
/p:username="USERNAME"
/p:password=PASSWORD
/p:AllowUntrustedCertificate=True
/P:CreatePackageOnPublish=True
/p:DeployIisAppPath=SITE-URL
/p:MSDeployPublishMethod=RemoteAgent
/p:IgnoreDeployManagedRuntimeVersion=True
I had exactly the same issue! I've posted the solution I used over at: MsBuild not finding publish profile
Basics were:
Install the Azure SDK 1.8 on the build server
Force the /P:PublishProfileRootFolder value to ensure MSBuild can locate the publish profile
Ensure that you have the Microsoft Web Developer Tools feature installed for Visual Studio. This was missing on my build agent but once I added it the TeamCity build worked just fine.
This can happen when the build target paths are missing from your MSBuild directory. Instead of trying to get those to line up on every developer machine, install the targets from the Nuget. That way it will always be the same for everyone, regardless of how their machine is setup.
When building a CLR Storedprocedure Project using MSBuild on our build server (Team City) we're getting the following error:
error MSB4019: The imported project
"C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\SqlServer.targets"
was not found. Confirm that the path
in the declaration is
correct, and that the file exists on
disk
I've checked to see if the file exists on disk and sure enough it doesn't. I've checked on my own machine and it does exist.
I don't really want to start copying over files manually to the build server.
Here's the line from the csproj file which is being imported to the proj file:
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<Import Project="$(MSBuildToolsPath)\SqlServer.targets" />
Here's the line from the proj file which is being run by our Team City Server:
<Import Project="..\$(ProjectName).csproj"/>
My question is really:
Where does this file comes from? Is it part of the Visual Studio install for example.. Or is there some re-distribution package somewhere to allow me to compile this project on our build server?
Thanks
BTW.. if i just copy the file onto the Build server it does actually work.
Dave
Looks like it's part of the v2.0 framework install that gets moved into the v3.5 directory after that's added. You can either reinstall v2.0 of the framework or manually copy the file out of the v3.5 folder.
Up to Visual Studio 2012, the SqlServer.targets was deployed on the .NET Framework's msbuild.exe location, like
c:\Windows\Microsoft.NET\Framework\v4.0.30319\
c:\Windows\Microsoft.NET\Framework\v3.5\
c:\Windows\Microsoft.NET\Framework\v2.0\
In modern versions, from Visual Studio 2013 on, the MSBuild tool is included with Visual Studio, and the MSBuild.exe and .targets files are deployed in their own folder. For example fo Visual Studio 2013:
c:\Program Files (x86)\MSBuild\12.0\Bin\
(NOTE: 12.0 is the "internal" version number of VS2013)
IMPORTANT NOTE: SqlServer.targets only exists if you install SQL Server Data Tools in your Visual Studio Deployment.