I'm getting the following error from a build I'm running through TeamCity on my development machine:
[ResolveServiceConfiguration] WATMessage
[16:02:05][WATMessage] C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Windows Azure Tools\1.7\Microsoft.WindowsAzure.targets(354, 5): No default service configuration "ServiceConfiguration.cscfg" could be found in the project.
[16:02:05][Xxx.Azure.Production\Xxx.Azure.Production.ccproj] Project Xxx.Azure.Production\Xxx.Azure.Production.ccproj failed.
The same solution builds okay in VS.NET.
I think what I need to do is set the TargetProfile for each of the Azure projects (there's more than one complaining) to override the default of Cloud but I can't find out where to do this.
So how do I set the Target Profile for an Azure project?
Have you tried setting the target profile at command line?
/p:TargetProfile=MyProfile
Given an Azure service configuration file named "ServiceConfiguration.Production.cscfg":
In your TeamCity project build configuration, go to Build Parameters (step 7)
Add a system property with the name "system.TargetProfile" and a value of "Production"
This pattern applies for any named configuration in the format ServiceConfiguration.[your profile].cscfg.
To work around this problem I have created ServiceConfiguration.Cloud.cscfg for each Azure project using the .cscfg that was being set in the definition.
In my case, I renamed the ServiceConfiguration.Cloud.csfg file, and since the build agent will first look for that file because the default TargetProfile is "Cloud", I had to re-create the ServiceConfiguration.Cloud.csfg file in the same location, then went into the .ccproj file and added this line under the <ItemGroup> node:
<ServiceConfiguration Include="ServiceConfiguration.Cloud.csfg" />
Then I rebuilt and the problem was solved.
Related
I'm trying to publish a bunch of web services and a web site via command line using MSBuild. When I publish, the web services publish successfully but my web site does n't upon checking the logs, I've realized that msbuild is ignoring the build configurations in the specified publish profile and is using the default configurations i.e. Debug|AnyCpu. I've roamed around SO and the internet and found some articles but none worked for me.
Other SO article
I would like to be able to make MSBuild understand that I am trying to publish via the publishprofile. I tested the publish profile and visual studio and was able to execute a publish.
Here is my msbuild command
C:\Windows\Microsoft.NET\Framework\v4.0.30319\MsBuild.exe "PATH_TO_PROJECT\PROJECT.csproj" /nodeReuse:false /nologo /p:PublishProfile="FolderProfile" /p:DeployOnBuild=True
Logs
The target "_ConvertPdbFiles" listed in a BeforeTargets attribute at
"C:\Program Files
(x86)\MSBuild\4.0\Microsoft.Common.targets\ImportAfter\Xamarin.Common.targets
(34,37)" does not exist in the project, and will be ignored. The
target "_CollectPdbFiles" listed in an AfterTargets attribute at
"C:\Program Files
(x86)\MSBuild\4.0\Microsoft.Common.targets\ImportAfter\Xamarin.Common.targets
(34,70)" does not exist in the project, and will be ignored. The
target "_CollectMdbFiles" listed in a BeforeTargets attribute at
"C:\Program Files
(x86)\MSBuild\4.0\Microsoft.Common.targets\ImportAfter\Xamarin.Common.targets
(41,38)" does not exist in the project, and will be ignored. The
target "_CopyMdbFiles" listed in an AfterTargets attribute at
"C:\Program Files
(x86)\MSBuild\4.0\Microsoft.Common.targets\ImportAfter\Xamarin.Common.targets
(41,71)" does not exist in the project, and will be ignored. Project
"C:\Git\DXT\DXT.UI.WEB.APP.DEVICES\Dxt.Web\Dxt.Web.csproj" on node 1
(default targets).
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(609,5):
error : The OutputPath property is not set for project
'Dxt.Web.csproj'. Please check to make sure that you have specified a
valid combination of Configuration and Platform for this project.
Configuration='Debug' Platform='AnyCPU'. You may be seeing this
message because you are trying to build a project without a solution
file, and have specified a non-default Configuration or Platform that
doesn't exist for this project.
[C:\Git\DXT\DXT.UI.WEB.APP.DEVICES\Dxt.Web\Dxt.Web.csproj] Done
Building Project
"C:\Git\DXT\DXT.UI.WEB.APP.DEVICES\Dxt.Web\Dxt.Web.csproj" (default
targets) -- FAILED.
Build FAILED.
"C:\Git\DXT\DXT.UI.WEB.APP.DEVICES\Dxt.Web\Dxt.Web.csproj" (default
target) (1) -> (_CheckForInvalidConfigurationAndPlatform target) ->
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(609,5):
error : The OutputPath property is not set for project
'Dxt.Web.csproj'. Please check to make sure that you have specified a
valid combination of Configuration and Platform for this project.
Configuration='Debug' Platform='AnyCPU'. You may be seeing this
message because you are trying to build a project without a solution
file, and have specified a non-default Configuration or Platform that
doesn't exist for this project.
[C:\Git\DXT\DXT.UI.WEB.APP.DEVICES\Dxt.Web\Dxt.Web.csproj]
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:00.09
I tried supplying a specific configuration to avoid the Debug|AnyCpu combo but encountered errors since the website has a custom Configuration called Release.Custom and depends on projects that do not have that configuration.
Any help is much appreciated.
If anyone encounters this, I was able to fix my error by changing the value of the Configuration tag to my custom BuildConfiguration i.e. "Release.Custom". It's very stupid considering I've spent a day on this.
I'm having some issues deploying an Azure WebJob using Visual Studio Team Services (VSTS).
The WebJob seems to be deployed successfully but it breaks the Azure website that is hosted in the same App Service! I don't have this problem if I deploy using VS2013.
This is my build task that generates the WebJob deployment package:
And this is my deployment task:
There are no errors when I deploy the Azure WebJob. If I go to the Azure Portal I see the WebJob is there, and it runs successfully. WebJob files are copied into the wwwroot\App_Data\jobs\triggered\RemoveExpiredDids folder as expected, but the problem is that some other files will be copied into the wwwroot\App_Data\bin folder, which will break the existing website that was already deployed into that App Service!!!
So I decided to find out why this was happening. After downloading and extracting the deployment package I saw there are 2 folders (app_data and bin) and the scheduler file (settings.job):
This explains why some assemblies are coppied into the wwwroot\App_Data\bin of the App Service. The strange thing is that this doesn't happen when deploying from VS2013!!! I took a look into the MSBuild log and found the following line:
Object dirPath ([app service name]\bin) skipped due to skip directive 'SkipBinFolderOnDeploy'.
Concluding, bin folder is included when deploying the Azure WebJob from VSTS but is excluded when deploying it from VS2013.
So my question is: how to prevent the bin folder from being deployed when using VSTS? Is there any MSBuild parameter/flag to do this?
I've had issue with this particular problem as well.
The latest method I found is using Web Deploy Operation Settings , -skip:Directory= (in this case it would be -skip:Directory='\\bin') when you create your azure deploy task in the release definition (Additional arguments). I've seen that this indeed excludes the bin folder from the update actions (result).
Let me know if this helps you in any way.
Refer to these ways to deploy webjob to azure:
Modify Visual Studio Build task to deploy webjob with FileSystem (MSBuild Arguments: /p:DeployOnBuild=true /p:WebPublishMethod=FileSystem /p:publishUrl="$(build.artifactstagingdirectory)\\WebJob" /p:DeployDefaultTarget=WebPublish)
Add Delete Files task to release definition to delete bin folder (Source Folder: $(System.DefaultWorkingDirectory)/WebJobVnext/drop/WebJob); Contents:bin)
Modify Azure App Service Deploy task (1. Uncheck Publish using Web Deploy option. 2. Package or folder: $(System.DefaultWorkingDirectory)/[artifact name] /drop/WebJob)
I was finally able to fix it, thanks #starain-MSFT for pointing me in the right direction. I had to make some minor changes, though. This is the task that creates the deployment package:
MSBuild arguments:
/p:DeployOnBuild=true /p:WebPublishMethod=FileSystem /p:DeployDefaultTarget=WebPublish /p:Configuration=$(BuildConfiguration) /p:OutputPath=.\bin\ /p:publishUrl="$(build.artifactstagingdirectory)\temp\WebJob"
The difference here comparing to #starain-MSFT answer is that I had to add the /p:OutputPath= parameter, otherwise I'd get the following error:
The OutputPath property is not set for project
After generating the package, I delete the bin folder and zip it (this reduces the build time).
This is my deployment task:
Please note that $(DeploymentPackagePath) is the path to the zip file that contains the deployment package, as mentioned before. It doesn't matter if you deploy the package as a zip file or if you unzip it and deploy the folder, it works both ways.
I'm using Win10 64bit OS, with Wix3.11RC Toolset installed. My VS2017 have created a Wix v3 installer Project. Our team is using TeamCity9.1 as the CI tool.
Now I want to make the Build Agent in TeamCity to support wixproj build without touch CI server settings(I don't have privilege ). I basically follow some tutorials to checked in all necessary Wix build files(the wix Bin folder, and the wix.targets ) which is put in a relative path to the source code, now I'm blocked with the path issue in editing .wixproj file, the official doc said:
http://wixtoolset.org/documentation/manual/v3/msbuild/daily_builds.html
<PropertyGroup>
<WixToolPath>$(SourceCodeControlRoot)\wix\[[Version]]\</WixToolPath>
<WixTargetsPath>$(WixToolPath)Wix.targets</WixTargetsPath>
<WixTasksPath>$(WixToolPath)wixtasks.dll</WixTasksPath>
</PropertyGroup>
And this is mine:
<PropertyGroup>
<WixToolPath>..\..\wix\3.11\</WixToolPath>
<WixTargetsPath>$(WixToolPath)targetsFile\v3.x\wix.targets</WixTargetsPath>
<WixTasksPath>$(WixToolPath)wixtasks.dll</WixTasksPath>
</PropertyGroup>
The reason I'm using the relative path for WixToolPath is the $(SourceCodeControlRoot) was resolved as D:\ here, but actually the source code will be checked out by CI server and put under a random folder like D:\ABC\f14c7929aa63f1fc. By my configuration, the local build even can't go through, the build error indicates the WixTasksPath had been resolved to a non-existed path: C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x\..\..\wix\3.11\wixtasks.dll
So how can I achieve? thanks!
One of the approaches you can try is to change the path in the file to the absolute path using TeamCity-provided references before invoking the tool. In TeamCity settings you can reference the checkout directory path as %system.teamcity.build.checkoutDir% or use ${teamcity.build.checkoutDir} within MSBuild step if run as MSBuild build step.
You can do the replacement in the first build step or just use TeamCity file content replacer to change the old value to new one.
just use
<WixTasksPath>wixtasks.dll</WixTasksPath>
this worked for me.
We have a TFS build definition set up where we pass the following extra MSBuild arguments in:
/p:DeployOnBuild=true;DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder;_PackageTempDir="\\server\build";AutoParameterizationWebConfigConnectionStrings=false
This has been detailed elsewhere as a way to have the published files copied to a specific location instead of generating a deploy package.
This unfortunately does not work on our build server, however if I run the exact same msbuild command line as called by TFS on my dev machine then it works perfectly and copies the output files to the location.
I have checked the log file and there is no errors, it just seems to completely skip the publish/deploy step.
Done building target "_BuiltWebOutputGroupOutput" in project "xyz.csproj".
Target "PrepareForRun" in file "c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets" from project "C:\Builds\2\xyz\xyz build\Sources\xyz.Web\xyz.Web.csproj" (target "CoreBuild" depends on it):
whereas on my local machine, after _BuiltWebOutputGroupOutput target is run the package target runs and deploys the files correctly.
I have tried using different paths and even setting the properties in the project file but it seems to make no difference. My local solution and project files are the same as in the repository that the TFS build is using. Is there something config related on our build server or with the build agent that would cause the packaging target not to run?
I was having a similar problem today and found a fix so it maybe worth a look for you. Here
Normally when a Developer compiles a certain mixed C++/C# solution locally on their machine at our company, they employ the use of a .vssettings configuration file. One of the things included in this config file is reference to various directory paths for Lib and Include files.
However, our buildAgent machines (using TeamCity) are set up to be sterile, and have the bare minimum installed on them required to build any given solution/project. This means the above exampled mixed C++/C# project wont have access to the IDE's configuration where things like include search paths were set. TC accounts for this by allowing you to set all sorts of variables for any given buildConfiguration (or even by buildAgent)....
But how do I get an Include search path to WORK in TC? I'm copying down from Source Control (Perforce) a copy local of what I want Included (1), and then trying to define an Environment Variable (2) -- and yet TC fails the build (3).
I'm sure I have something configured wrong, but for the life of me cant figure out what!
Any help would be most appreciated,
blong
(1) VSC Client Mapping - Perforce
//depot/OpenSource/Boost-1.33.0/boost/... //team-city-agent/OpenSource/boost/...
(2) buildConfig Environment Variable definition
env.Include = %system.teamcity.build.checkoutDir%\OpenSource
(3) TC build log snippet
[16:57:39]: [Project "xxx.sln" (Build target(s)):] e:\buildagent\work\ef1853a454da9d94\xxx\rowsbase.cpp(5, 0): error C1083: Cannot open include file: 'boost/dynamic_bitset.hpp': No such file or directory
First, you should try to compile the solution yourself with msbuild or vcbuild on the command line, because TeamCity will do something similar. If necessary, add msbuild folder to the Path system variable. Then open the command line and type:
msbuild.exe YourSolution.sln
or
msbuild.exe YourSolution.sln /p:Configuration=Release
depending whether you want to do so in debug or release mode. This should give the same C1083 errors.
Here's the fix:
Add the path of the directories you need to add an environment variable (in fact, system variable) that I suggest you call INCLUDE.
Open the file VCProjectEngine.dll.config.xml in folder .../Microsoft Visual Studio 9.0/VC/vcpackages/.
Add the INCLUDE system variable to the include line. To me it came to replacing:
Include="$(VCInstallDir)include;$(VCInstallDir)atlmfc\include;$(WindowsSdkDir)\include;$(FrameworkSDKDir)include"
with:
Include="$(VCInstallDir)include;$(VCInstallDir)atlmfc\include;$(WindowsSdkDir)\include;$(FrameworkSDKDir)include;$(INCLUDE)"
Test it works: Open a new command line (need to after you change environment variables for them to be taken into account) and try to build your solution as shown above. This has worked for me to build C++ solutions with files that #include .
Now let's have it work in TeamCity too. You can run a TC build at this point to see whether it does, but it didn't for me. Go to the "Properties and environment variables" of your TC build configuration, and add an environment variable named INCLUDE with value the same path(s) as in the INCLUDE system variable above.
Now this should work. Hope it helps.
Setting the Build Agent Service to run as a non "local System" account fixed my problem.
I ran into a problem were my C++ projects would build in Visual Studio on the build agent, but they failed when built through TC. The build agent is running windows and agent is running as a service (TeamCity Build Agent Service). The problem was that the service was being run as "Local System" instead of the user that configured Visual Studio. I change service so it would log on as the "build" user and everything worked fine.