From my local machine to a development server, Web Deploy 3.0 works fine with Visual Studio 2012 publish profiles using the following command:
msbuild .\myproj.csproj /verbosity:d /p:DeployOnBuild=true;PublishProfile=Develop;VisualStudioVersion=11.0;AllowUntrustedCertificate=true;username=xx;password=xx
When running this same command from the CI server (happens to be Jenkins but this should apply to any), the command finishes successfully, but no web site is ever deployed.
When comparing the log output, a large section appears to be skipped by the build server. It is occuring just after the 2 lines listed below (these 2 lines of output are identical when running local or on the CI server):
Target "PrepareForRun" in file
"C:\windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets" from project
"C:_Application\proj\src\proj.Web\proj.Web.csproj" (target
"CoreBuild" depends on it):
Done building target "PrepareForRun" in project "proj.Web.csproj".
When running locally, this is followed up by what is shown below (plus hundreds more lines of logging):
Target "InsertAdditionalWebCofigConnectionStrings" skipped, due to false condition;
($(InsertAdditionalWebCofigConnectionStrings) And '#(_ConnectionStringsToInsert)' != '')
was evaluated as (True And '' != '').
Target "_CleanWPPIfNeedTo" in file "C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.targets" from
project "C:_Application\proj\src\proj.Web\proj.Web.csproj"
(target "PipelineCollectFilesPhase" depends on it):
Task "ReadLinesFromFile"
On the CI server, this directory appears to be missing:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.targets
Would a missing targets cause it to fail silently? Where does this folder come from (missing the entire Web folder on the CI server)?
Have you installed Visual Studio on your build server? It seems like a strange thing to do at first (and isn't strictly necessary), but it certainly in the easiest way to resolve all these issues.
You can manually copy the required targets files from your PC on to the build server, but you'll be playing a trial and error game to get it to work.
Also if MS release new out of band updates, like Asp.Net and Web Tool 2012.2 which they did recently, it's a much easier install procedure for the build server than to try and work out what targets have changed and copy them up manually.
Let me know if this helps.
Related
I'm attempting to run some selenium tests in my solution that are in a project called SA.SEPA.Web.UI.Selenium as part of a build definition in VSTS, but it is failing to run the Visual Studio Test task with the error...
No test assemblies found matching the pattern: **\*Selenium*.dll.
Search folder is set to - $(System.DefaultWorkingDirectory)
Preceding tasks are a nuget restore and build solution
Can anyone help?
You are specifying $(System.DefaultWorkingDirectory) as the search folder. By default (unless overridden), this points to the Source folder on the Agent.
If you are instructing MSBuild (using the OutDir parameter) to output your assemblies in a specific location then you should use that location.
Edit: If this is an On-premises Agent, it should also be running in interactive mode (not service) if you want to execute any UI tests
I ran into this same error but it was a different cause, so I'm adding my solution here.
I was getting the "no test assemblies found" error when trying to run Selenium tests with VSTS as part of a build.
My problem turned out to be that the test assemblies were not checked into change control (git, through VS2017), and therefore were not part of the build. The folders that contain the test assemblies were ignored during my original check-in by default. Once I added those folders to my repository, the build could find the tests and run them.
Hi I am banging my head for last few days.
Here is the situation ...
1. I have VSO account which maintains the TFS in cloud.
2. Installed a build server/agent on another machine. (Works fine)
3. Tried to build(XAML build) one solution using that server/controller.
4. Got an error saying ...
"The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk."
The build server and the agents are from TFS 2015 and the project is a Visual Studio 2015 project using framework 4.6. I was expecting "v14" folder for target files during build. Why it is trying to find things from "v11" folder ? And how do I solve this.
I know I can copy files to "v11" but I don't want to escape the facts. There should be a reason and a proper fix. Any help would be nice.
Several solutions for you to correct this error:
S1: Install MSBuild.Microsoft.VisualStudio.Web.targets from NuGet gallery via running the following command: Install-Package MSBuild.Microsoft.VisualStudio.Web.targets.
Then replace the following line in your .proj file
<Import Project="$(MSBuildBinPath)\Microsoft.WebApplication.targets" />
with
<Import Project="$..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0\tools\VSToolsPath\WebApplications" />
S2: Set the /p:VisualStudioVersion=12.0 MSBuild argument in the build definition.
S3: Copy the Microsoft.VisualStudio.Web.targets file to the C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications folder on the build agent machine.
S4: Install VS2012 on the TFS build agent machine just like Patrick mentioned above.
And related cases: Microsoft.WebApplication.targets and Microsoft.WebApplication.targets was not found, on the build server. What's your solution?
The WebApplications\Microsoft.WebApplication.targets (11.0) (which comes from VS2012) is referenced in your web application, so the Visual Studio 2012 should be installed on your build server to resolve this issue.
Be note that, to guarantee TFS build runs successful, you should make sure your build agent machine has the some environment as dev machine.
Did you restore a previous collection on TFS 2015 from a previous TFS version? Did your solution or any projects in your solution get created prior to VS2015?
When I run my TeamCity build with the only build step being of runner type Visual Studio (sln), I get the following error:
C:\TeamCity\buildAgent\work\4978ec6ee0ade5b4\Test\Code\Test.sln(2, 1): error MSB4025: The project file could not be loaded. Data at the root level is invalid. Line 2, position 1.
This is on a dedicated CI server running TeamCity Professional 8.1.1 (build 29939). There are several other successfully-running builds on this server.
The odd bit is that the same build runs successfully on TeamCity on my dev machine. I followed an answer to a similar question, and copied the specified folders across, but that didn't help.
I'm sure the project/solution file isn't invalid because in addition to the build running on my dev box, I have opened the solution in Visual Studio and built it there with no problems.
Any suggestions?
I just fixed this.
Look inside the Test.sln file for Project or EndProject tags that aren't closed. For us, the EndProject was missing and it broke on teamcity, but no issues in Visual Studio.
It seems the TeamCity error message will occur for any number of root causes. In my case the problem occurred because a line inside the GlobalSection(NestedProjects) section was referring to a project Guid which didn't relate to any project defined in the Solution file.
As with the previous post I didn't have any issues building in Visual Studio. I only got a more helpful error message that allowed me to discover what the real problem was when I built using msbuild.
See https://therightjoin.wordpress.com/2014/07/04/msb4025-the-project-file-could-not-be-loaded-data-at-the-root-level-is-invalid-error-when-building-ssdt-project-in-teamcity for another example, and where using msbuild helped identify the true problem.
In our case, it was a duplicate project reference in the solution file (caused by near simultaneous commits and an automatic merge).
In our situation the problem was specifying a ToolsVersion that was not installed on that machine. (14 which VS2015 has but VS2017 does not have by default)
In my case, after merging, in .sln file, it was a mismatch of lines under
GlobalSection(NestedProjects) = preSolution
{6B971E15-6B61-4AA8-9B93-9639C23269C3} = {9A14E7EF-3FA1-4B9A-B413-C550B3E5AC62}
{54D14F01-D576-4DE6-9404-D21AD0DC4916} = {9A14E7EF-3FA1-4B9A-B413-C550B3E5AC62}
... (was some extra entry here )
...
EndGlobalSection
section. In clear words, there were some extra lines added after merging. So, If you have merged, please compare two solution files manually. You can start with total line numbers in both files.
In another Case
We had a blank lines - so make sure any blank lines are removed!
Hope this helps some else too!
I got this same error with Jenkins. It turns out the root Jenkins folder was set to C:\Program Files (x86)\ and it didn't have write access to bin and obj directories.
Error:
error MSB4025: The project file could not be loaded. Data at the root level is invalid.
I launched cmd as Administrator and ran this:
"C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" "C:\Program Files (x86)\Jenkins\workspace\BuildBI_1\Reports\Test\ReportsTests.sln" /t:Build /p:RunOctoPack=true
And that gave me clues about not being able to write to bin and obj.
This worked for me-
You can install Build Tools for Visual Studio 2017, make sure to select C++ tools, Windows 10 SDK and MSBuild and your set.
Use MSBuild to identify the underlying problem:
$> msbuild mysolution.sln
Gave me this beauty with the correct error line number:
If msbuild cannot be accessed like that from the command line / powershell, try to find the MSBuild.exe shipped with VisualStudio, e.g. C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\amd64\MSBuild.exe.
VisualStudio itself seems to be very "tolerant" against errors / inconsistencies in the solution file, so having it open in VS is no guarantee for the sln file being correct.
I fixed it by updating the solution file.
Another possible problem (and resolution): I had a stray unused solution file in my repo, pointing to who-knows-where, and the MSBUILD step in my Azure DevOps pipeline was set to **\*.sln.
I have a solution in VS2010 and it has three project, two of these projects have web config file, the projects have web config transformation for each environment (dev, test and prod).
At the process for TFS build option, I have the at the MSBuild Arguments : /p:DeployOnBuild=True
Everything looks good, the drop folder, the zip files and all structure for the final deployment. The issue I am facing the web config for test and prod is not created correctly after the final deployment, I could see at the drop folders the file projectName.SetParameters.xml, it contains the values for development when the build has been QUEUE for Test and Prod. One of the project has the correct web config (test and prod) but the other project has always the dev webconfig.
Is it a bug in the MS Build? What am I missing in the build parameters?
When I create a build deployment package the web config transformation creates the correct web config file, no issues with this process, but I do not want to use build deployment package to deploy my solution.
Any help will be appreciated.
Thank you.
In your Build Definition you probably defined the Configurations to use. Part of that also defines something like Any CPU or x86. As it turns out the solution the Platform "Any CPU" has a space where in the project files the Platform Any CPU does not have a space.
I found the best way to get around this was to leave the Platform blank and only put in the configuration name. VS will pop up a warning letting you know that there is data missing, you can just hit "Yes" to save it anyways. Alternatively you can just type in your configurations like the following |Release,|Debug.
The pattern is [PlatformName]|[ConfigurationName],[PlatformName]|[ConfigurationName],...
On my development laptop I have only VS2012 RC installed, and I am successfully able to hook into the new MSDeploy .pubxml plumbing (DeployOnBuild and PublishProfile settings) from powershell (via psake) to deploy my web site to our test server.
However, on my build server, I initially had VS2010 SP1 installed, and I've now additionally installed the 2012 RC (I have other builds on this machine that are still .NET 4).
When running the same script with exactly the same parameters, I see different results between my dev machine and the build server. The command I'm running is
exec { msbuild "Website\WebSite.csproj" /m p:DeployOnBuild=True /p:PublishProfile=MyTestProfile }
On the build server, this does not in fact trigger MSDeploy, but simply the packaging bits that zip the site up and makes a deployment package. My machine successfully picks the pubxml file up and does a successful deployment.
Eventually, I believe I've traced the problem to the file Microsoft.Web.Publishing.targets. On my dev machine I have only
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web
but the server additionally has
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web
and it seems like this file (without knowledge of the .pubxml stuff) is what's being used there.
Has anybody got any idea what I need to twiddle (preferably within my own msbuild files so I don't screw up anything else on the build server for the 4.0 builds) to get msbuild to pick up the v11.0 version of the file and thereby use my .pubxml file?
That is interesting it should be picking up the latest (v11.0), seems like there is a bug here . This is controlled by the MSBuild property VisualStudioVersion.
Here are the rules for how this value is populated at build time.
1. If VisualStudioVersion is defined as an environment variable or a global property (e.g. /p: on the command line) that wins. This is how Dev11 & the Dev11 command prompt are always v11 – they both define VSV as an environment variable
1. Otherwise, if there is a sub-toolset that matches the equivalent solution version (which is currently always file format version – 1), choose that
1. Otherwise, get the default version; 10.0 if Dev10 is installed, Highest-versioned sub-toolset version installed (currently always 11) otherwise
In your case since you are running into an issue you can pass in the property /p:VisualStudioVersion=11.0 to ensure that the correct targets are used.