Our web apps have a post build event that copies web.config files over depending on the configuration that's being built. I wasn't around when this was created, and no one from back then exists on the team today, but it looks like our CI/Deploy server requires it, so removing it isn't an option.
Error The command "
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\msbuild" "E:\{path}\UI.IX.csproj" /t:Transform /p:Configuration=Debug.Dev;Platform=AnyCPU
Xcopy E:\{path}\obj\Debug.Dev\Web.Config E:\{path}\. /F /R /Y
("E:\{Path}\IX.PostBuild\bin\Debug.Dev\IX.PostBuild.exe" 'E:\{Path}' 'E:\{path}\' Debug.Dev /S /Y /I /D /V /C)"
exited with code 5. Please verify that you have sufficient rights to run this command.
The post-build has 3 steps:
run MS Build to update the web.config with the correct config based on configuration management
Copy the web.config into the bin/obj directory
Run a PostBuild .exe file to copy files from one project to another
We're only seeing this error come up on a handful of computers from a new office, and it's not able to be reproduced.
Visual Studio is being ran as admin, by an admin
all commands in the Post-Build event can be ran through a Command Prompt without any error
removed all but msbuild.exe command from post build - still errors (this is the culprit)
Any thoughts on how to fix this error? I don't have this error on 5 machines, but out of 3 new ones in a new office, 2 have this error.
Update
On further inspection we found out that VS was installed by the local Admin prior to joining the domain. I am not sure if this would cause any issues with permissions, but we are re-installing VS on the domain account that will be running the system to see if that fixes anything.
The cause of this issue was Antivirus software. When it was building antivirus software was scanning the new files that were created, and during this scan, Visual Studio was unable to rewrite the files.
We added the source code folder to a list of excluded folders in the AV software and it builds properly now.
Related
I have a solution running on VS 2017 15.7.4 on Windows 7 and works on 6 machines.
On this new machine (same like the others), I am getting the following when I am trying to compile:
The command ""C:\Projects\MySolution\Source\.nuget\NuGet.exe" install "packages.config" -source "" -NonInteractive -RequireConsent -solutionDir "C:\Projects\MySolution\Source\ "" exited with code 1
Could not find file 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\packages.config'.
We tried showing detailed build log, but that wasn't helpful
We rebuilt the machine and same error persisted.
This is a corporate machine with local admin right user account. I am suspecting that the local admin rights might not be implemented properly.
Any suggestions?
NuGet with MSBuild Trying to locate the package.config in VS IDE
folder
Please try to give the full path to the packages.config file:
"C:\Projects\MySolution\Source\.nuget\NuGet.exe" install "<YourProjectPath>\packages.config" -source "C:\Projects\MySolution\Source\"
After hours of investigation, it turned out that the project name is the problem.
The project name (and the namespace) are as follow: MyCompany.MyProject.CMD
(CMD is actually real).
This project was compiling for ages on all machines, however, it didn't do on this particular machine.
We deleted the whole folder structure and recreated it and even formatted the machine.
We tried creating a new project from scratch and calling it the same name - Didn't compile
We tried creating a new project from scratch and called it a different name - Worked!
So solution was changing the project name to MyCompany.MyProject.SomethingElse sorted out the problem. I didn't add CMD as part of the project name, but I will never do and I will pass this to my kids as well.
I didn't want to investigate why it didn't work but CMD resembles the name of the Windows console, would that be the reason? I don't care to know.
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.
Using Team Foundation Server 2010 I am trying to unshelve a series of changes made by another developer on my team. This shelve set includes some Nuget packages which include dlls. I am receiving multiple errors along the lines of:
The item $/file/path/some.dll is locked for check-out by USER in workspace MACHINENAME.
In 2008 Mac Noland asserted in his blog post Unshelving files that have File Merging disabled that this error is caused by having file merging being disabled. Which makes good sense to have file merges disabled for binaries. Based on the error I am assuming that TFS 2010 is still utilizing the merge utility when unshelving (makes sense as to why). That said I do not want to enable file merging for dll files.
Unfortunately, understanding what is going on and fixing it are two different things. In TFS is there a way to unshelve binary files which were shelved by a different user?
If the user created the shelveset, but left everything checked out locally, you will receive this error. Since TFS usually allows only a single checkout for binary files, a shelveset can't be unshelved if it contains a binary file which is locked by another user.
You can attempt to unlock the file with the following command -
tf lock itemspec /lock:none /workspace:OtherUsersWorkspace
You should be able to determine the workspace from the error message, and you'll also need to specify the user - /workspace:WORKSPACE;userid
In my case my source code is located at below location in my work station
D:\TFS\Source\Development\Cars.
I opened Visual Studio Command Prompt under Visual Studio Tools and ran it as Administrator.
I changed my command prompt to move to
D:\TFS\Source\Development\Cars
Executed below line
D:\TFS\Source\Development\Cars> tf lock HE/* /lock:none /workspace:zigglerworkspace /login:ziggler /collection:ziggler1pxtfs01\WebProjects
zigglerworkspace - my workspace name
ziggler - my user name
ziggler1pxtfs01\WebProjects - TFS server url
This released locks on all files and folders under HE folder which is located at
D:\TFS\Source\Development\Cars\HE
Install Microsoft Team Foundation Server 2010 Power Tools
Add C:\Program Files (x86)\Microsoft Team Foundation Server 2010 Power Tools to your system path
cd c:[some location]\"destination workspace"
tfpt unshelve /migrate "shelveset name";otherUserName /source:"$/ProjectName/Main/Source" /target:"$/ProjectName/Main/Target"
I'm attempting to do a command line package deploy for our Windows Store Application.
My command line instructions are:
msbuild /m /p:Configuration=Debug /p:Platform=x86 /target:Build
I'm using VS2013 Professional with Windows 8.1
I get the following error:
C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v12.0\AppxPackage\Microsoft.AppXPackage.Targets(1224,9):
error APPX0002: Task 'GenerateAppxPackageRecipe' failed. Value cannot
be null.\r [C:\Path\Project.csproj]
C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v12.0\AppxPackage\Microsoft.AppXPackage.Targets(1224,9):
error APPX0002: Parameter name: source\r [C:\Path\Project.csproj]
How should I resolve this?
This error was resolved by using the correct version of msbuild.exe
On a clean build server with VS2013 installed, there are (at least) two copies of msbuild.exe installed. In our case the install locations were:
C:\Program Files (x86)\MSBuild\12.0\Bin\msbuild.exe
and
C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe
The one in the .Net Framework folder was the one that gave us the errors. Using the version installed in the Program Files folder resolved the issue.
It's impossible to help you without having the code which can reproduce the error. I suspect some property does not resolve correctly when building outside VS(eg VisualStudioVersion) and needs to be passed from command line. VS also uses msbuild to build your projects, so comparing build logs from VS and CMD should help you track down the problem.
I suggest, that you set visual studio's build output verbosity to diagnostic, clean solution, than build and capture the build log.
Then clean solution and build from command line with verbosity set to diagnostic and /fl switch(log to file, because diagnostic build log is way too long to analyse in console window).
Compare command-line output to VS output. Look for the differences. With diagnostic level of verbosity, chances are, you'll find out what's missing (I had similar issues with database projects failing to build from cmd due to VisualStudioVersion variable not being resolved correctly, so I passed it from command line).
NB: diagnostic log is very verbose which makes analysis hard: I'd start from detailed verbosity level.
I have deleted all files/folders from "project"/bin folder, cleaned the solution and rebuild with success !
For those facing the issue on hybrid app (corodova in my case), delete the build folder manually and re-build from VS.
Standard clean solution didn't do the job.
I'm trying to get a Lightswitch Project into Teamcity and have tried the following runner types:
Visual Studio (sln)
MSBuild
Command line (ran MSBuild through the command line)
All 3 runner types gave me the same error when building the Lightswitch solution:
The "UnpackExtensionsToProjectDir" task failed unexpectedly. System.NullReferenceException: Object reference not set to an instance of an object.
Lightswitch has already been installed on the server. Have tried building the solution manually using Visual Studio on the server and it builds fine. Have also tried building the solution via the command line (using MSBuild) and it builds fine too.
Would like to ask if somebody was able to get Lightswitch building nicely on TeamCity. Cheers.
This is how you build via the Command line (using TeamCity)
Pre-requisites)
First make sure you have not checked in the extensions directory, this can cause issues when building.
Check that you have installed any visual studio extensions on the build machine .ie ExtensionsMadeEasy. You can test this by opening the solution in visual studio on the build machine and trying to do a build.
Lastly, in TeamCity do not use the msbuild task, use command line to call msbuild.
Step 1)
msbuild.exe mylightswitchproject.lsproj /p:OutDir=C:\test\stuff\;configuration=Release
Step 2)
Create a bat file to copy your output to the correct folder structure.
robocopy C:\test\stuff\bin C:\test\localrelease\bin *.* /MIR
robocopy C:\test\stuff\Resources C:\test\localrelease\Resources *.* /MIR
robocopy C:\test\stuff\Web C:\test\localrelease\Web *.* /MIR
robocopy C:\test\stuff\ C:\test\localrelease\ ClientAccessPolicy.xml
robocopy C:\test\stuff\ C:\test\localrelease\ default.htm
robocopy C:\test\stuff\ C:\test\localrelease\ Home.aspx
robocopy C:\test\stuff\ C:\test\localrelease\ Login.aspx
robocopy C:\test\stuff\ C:\test\localrelease\ LogOff.aspx
robocopy C:\test\stuff\ C:\test\localrelease\ Silverlight.js
robocopy C:\test\stuff\ C:\test\localrelease\ web.config
You can now take this folder and release it to the next environment.
Finally, if you want to create a web deployment package, out the box visual studio 2010 does not support this. However, you can copy this into an existing website then "Export" your application into a package that is then ready for web deployment via powershell.
The previous answers didn't work for us but Yaegor's answer provided some direction.
The issue we had was extensions are installed at the user level, not the system level. This meant the MSBuild process could not find the required extensions.
Our solution was to use a user account on the build server, log into account, setup VS.NET such that the LS project builds, and then switch the TeamCity agent service to use the new user account.
With this we were able to use the Solution runner (which is preferable to the CLI runner since it provides better logging and reporting).
For not Lightswitch-specific part: If command line works from console, but fails in TeamCity, most probably the issue is in the user or running as a service. You might try running TeamCity agent with the same environment.
When command line works you can then try MSBuild and Solution runners.
I ran into the same error when trying to set up an automated build for a lightswitch application using bamboo. Turned out to be the version of msbuild being called. If the 64bit version is called (from bamboo or the command line) I get the error:
UnpackExtensionsToProjectDir" task failed unexpectedly.
Switching to the 32bit version of msbuild fixes the problem.
32bit Path: 'C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe'
64bit Path: 'C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe'