I'm generating a deploy package for my project by using the following script
"C:\Program Files (x86)\MSBuild\12.0\bin\msbuild.exe" MyProjectFile.csproj /t:Clean;Build;Package /p:Configuration="Debug" /m /P:Platform=AnyCPU
I've also added an MsDeploySkipRules item to skip over empty directories when the package is deployed, which is added in a custom skip actions target i've build.
<Target Name="AddSkipActions" AfterTargets="GenerateSkipRuleForAppData">
<MsDeploySkipRules Include="SkipEmptyDirectories">
<SkipAction></SkipAction>
<ObjectName></ObjectName>
<AbsolutePath></AbsolutePath>
<XPath>dirPath[count^(*^)=0]</XPath>
</MsDeploySkipRules>
The problem i'm experience is when the package is created, it's wrapping the xpath expression in double quotes within the deploy command file, like so:
-skip:xpath="dirPath[count^(*^)=0]"
When i run the command, i recieve the following error:
Error: 'dirPath[count^(*^)=0]' has an invalid token.
I can fix this by modifying the command file manually to the following:
-skip:xpath='dirPath[count^(*^)=0]'
Any ideas on how to fix the way the package is generated to use single quotes in place of double quotes - i've googled like crazy, but can't seem to find the same issue.
Fixed the issue, it was the exe used to generate the package.
I changed the msbuild path to "C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe" and after fixing some errors, it's now generating the xpath parameter in single quotes.
Related
I have a problem with building a Web Deployment Package from a Web Application Project (within a solution containing multiple projects, as well as multiple web applications).
This actually works
I can build the project just fine from the command line if I use this command for example:
msbuild D:\PathTo\Solution\Project\Project.csproj
/fl /flp:logfile="D:\buildadventures\Build.log";errorsonly;verbosity=diagnostic
/p:SolutionDir="D:\PathTo\Project\\";Configuration=Release;Platform=AnyCpu
But this does not work
But when I try the same command just a bit differently to build a deployment package for me like that:
msbuild D:\PathTo\Solution\Project\Project.csproj
/fl /flp:logfile="D:\buildadventures\Build.log";errorsonly;verbosity=diagnostic
/T:Package
/p:SolutionDir="D:\PathTo\Solution\\";Configuration=Release;Platform=AnyCpu;
PackageLocation="D:\buildadventures\Project.zip";
AutoParameterizationWebConfigConnectionStrings=false
...it fails miserably, spitting out hundreds of errors of the "The type or namespace name '' does not exist"-kind
And why does it work this way?
The strange thing however is, the second command I posted works fine if the first one was executed prior to that.
I suppose the tasks executed when doing a "normal" build are different to those that are executed when building a package, now I wonder in what way they are different.
What symptomatically seems to cause it
I noticed that in the project file of the project I want to build a package of contains a custom section towards the end:
<PropertyGroup>
<PreBuildEvent>
cscript $(ProjectDir)SvnRevision\svnrevision.vbs $(ProjectDir) $(ProjectDir)Version.cs
nuget install "$(ProjectDir)packages.config" -o "$(SolutionDir)Packages"
</PreBuildEvent>
</PropertyGroup>
This seems to be responsible for that difference; if I do a "normal" build I can see that after that a new "Packages" directory was created in my solution folder.
However, as you might have guessed, that directory is missing when I try to do the package creation command. I also do not run into this problem if I let Visual Studio create the package for me.
Maybe I do have to change the project file or passed properties to carry over this behavior for my package creation, too?
Or Is there maybe a way to force a "normal" build and then just append package creation to that somehow?
Silly me.
I was able to circumvent this issue by just calling multiple targets in my msbuild command such as that:
msbuild D:\PathTo\Solution\Project\Project.csproj
/fl /flp:logfile="D:\buildadventures\Build.log";errorsonly;verbosity=diagnostic
/t:Build;Package
/p:SolutionDir="D:\PathTo\Solution\\";Configuration=Release;Platform=AnyCpu;
PackageLocation="D:\buildadventures\Project.zip";
AutoParameterizationWebConfigConnectionStrings=false
When I'm trying to build my VC++ code using 2010 I'm getting the error message
> C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB6006: "cmd.exe" exited with code 1.
Please tell how to overcome this?
Navigate from Error List Tab to the Visual Studios Output folder by one of the following:
Select tab Output in standard VS view at the bottom
Click in Menubar View > Output or Ctrl+Alt+O
where Show output from <build> should be selected.
You can find out more by analyzing the output logs.
In my case it was an error in the Cmake step, see below. It could be in any build step, as described in the other answers.
> -- Build Type is debug
> CMake Error in CMakeLists.txt:
> A logical block opening on the line
> <path_to_file:line_number>
> is not closed.
error MSB6006: "cmd.exe" exited with code -Solved
I also face this problem . In my case it is due to output exe already running .I solved my problem simply close the application instance before building.
I had the same problem today, while I was upgrading some VC6 project to VC2012.
In my case, it was because some of the operation in Custom Built Steps failed.
In project properties, go to Custom Build Step, you can see there maybe some something in command line edit box. Open a windows prompt and paste the command to it. Run, check if there is something wrong and fix it.
If there is no command line in the project property Custom Built Step, maybe you should check properties of every single file of the project.
If the command line has some macro, replace it with an actual value.
Or you can echo the command in VS output window:
cd %(somedir)%
echo %(somedir)%
You won't miss it this way.
I solved this. double click this error leads to behavior.
open .vcxproj file of your project
search for tag
check carefully what's going inside this tag, the path is right? difference between debug and release, and fix it
clean and rebuild
for my case. a miss match of debug and release mod kills my afternoon.
<Command Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">copy ..\vc2005\%(Filename)%(Extension) ..\..\cvd\
</Command>
<Command Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">copy ..\vc2005\%(Filename)%(Extension) ..\..\cvd\
</Command>
<Outputs Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">..\..\cvd\%(Filename)%(Extension);%(Outputs)</Outputs>
<Outputs Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">..\..\cvd\%(Filename)%(Extension);%(Outputs)</Outputs>
<Command Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">copy ..\vc2005\%(Filename)%(Extension) ..\..\cvd\
</Command>
<Command Condition="'$(Configuration)|$(Platform)'=='Release|x64'">copy %(Filename)%(Extension) ..\..\cvd\
</Command>
<Outputs Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">..\..\cvd\%(Filename)%(Extension);%(Outputs)</Outputs>
<Outputs Condition="'$(Configuration)|$(Platform)'=='Release|x64'">..\..\cvd\%(Filename)%(Extension);%(Outputs)</Outputs>
</CustomBuild>
Actually Just delete the build ( clean it ) , then restart the compiler , build it again problem solved .
I also faced similar issue.
My source path had one directory with 'space' (D:/source 2012). I resolved this by removing the space (D:/source2012).
For the sake of future readers. My problem was that I was specifying an incompatible openssl library to build my program through CMAKE. Projects were generated but build started failing with this error without any other useful information or error. Verbose cmake/compilation logs didn't help either.
My take away lesson is that cross check the incompatibilities in case your program has dependencies on the any other third party library.
Simple and better solution :
%WINDIR%\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe MyProject.sln
I make a bat file like this
%WINDIR%\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe D:\GESTION-SOMECOPA\GestionCommercial\GestionCommercial.sln
pause
Then I can see all errors and correct them. Because when you change the folder name (without spaces as seen above) you will have another problems. Visual Studio 2015 works fine after this.
When working with a version control system where all files are read only until checked out (like Perforce), the problem may be that you accidentally submitted into this version control system one of the VS files (like filters, for example) and the file thus cannot be overridden during build.
Just go to your working directory and check that none of VS solution related files and none of temporary created files (like all moc_ and ui_ prefixed files in QT, for example) is read only.
I was in a similar situation to the one described by "irsis".
I configured the project through CMAKE, and in CmakeList, I linked the OpenCV library to the project. However, when I updated the OpenCV version for another project, the path was changed and error occurred.
Check path of all related library.
Another solution could be, that you deleted a file from your Project by just removing it in your file system, instead of removing it within your project.
I've been doing a few mods on the open-source MarkdownDeep but I'm having trouble getting a release out - the project includes a post-build task to do some package-ing using Nuget.exe.
I can execute the command without errors from a dos box, but the step always fails (with Error: 9009 when run from VisualStudio as part of a Release build configuration.
Can anyone think why this is?
I would guess that when you are running manually from the command line you are either,
executing 'locally', the working directory is that of the required paths used in the build step
you are fully qualifying paths appropriately
The bottom line would seem that the path/s do not work out when executed from Visual Studio (can't find directory / file required to perform an operation, due to line-breakage, file not present in the PATH environment variable, and the like).
Pre- and post-build steps in Visual Studio get 'converted' into a single batch script and executed, the paths in this step should be properly enclosed in quotes, absolutely or relatively specified etc. but ultimately need to be able to properly expand/resolve to complete paths.
As an example, I'll quote the following snippet:
SvcUtil.exe parameter1 parameter2 will fail
C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\SvcUtil.exe
parameter1 parameter2 will fail
"C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\SvcUtil.exe"
parameter1 parameter2 will do.
How can I make a project file (VS 2008) that just has some data files in and has no built output?
I can make an empty project and add my data files to it (which get copied to the output folder
), but it produces an EmptyProject.dll after I do a build. I want just my data files in the output directory and not some empty DLL or EXE.
I want the data files to be the only thing in this project as the project will be shared in a couple of solutions.
Our application is C#. All of our normal code projects are C#.
The data files are schemas (XSD). I want these schemas to be in the output folder, but I don't want them included with an existing project. I would like a project named "Schemas" that has nothing in except the XSD files and does nothing except copy the XSD files to the output folder. I would like this in a project file so that the same schemas project can be referenced in multiple solutions.
I don't know of a way to suppress the creation of the .dll file. BUT... here's an easy workaround. In the project properties, Build Events tab, write a Post-build event command line that will delete the file. Something like:
del path\filename.dll
Expanding on Scott's answer:
Create a new project of type Empty project
In Properties->Application, change Output type to Class Library
In Properties->Build->Advanced, change Debug Info to None
In Properties->Build Events, set the Post-build event command line to del $(TargetPath)
That way, the project creates only a DLL, which gets deleted. At the same time, the "copy to output directory" settings on your data files is respected.
Possibly another way is editing the csproj file by replacing this:
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
with this:
<Target Name="Build" />
<Target Name="Rebuild" />
Then builds don't create anything. It worked for me.
Same general idea should work for any xxproj file. Just replace the <Import Project...> tags with the <Target...> tags.
I'd be interested in knowing if this causes any issues or doesn't work for anyone.
What do you need a project for if you're not building it?
You can use solution folders to "store" files...
Why not just disable building this project for all configurations (use the Configuration Manager) - that way it won't build.
Great stuff. Expanding on Scott > Daniel's answer:
Safe to remove all References and Properties (AssemblyInfo.cs)
If it is a node/grunt/gulp project then you can invoke it in your Build Events > *Post-build event command line * eg: gulp build or gulp clean
Perhaps you can add removal or obj and bin output folders to your node/grunt/gulp clean scripts mitigating the need for del $(TargetPath)
On a successful build, I wish to copy the contents of the output directory to a different location under the same "base" folder. This parent folder is a relative part and can vary based on Source Control settings.
I have listed a few of the Macro values available to me ...
$(SolutionDir) = D:\GlobalDir\Version\AppName\Solution1\build
$(ProjectDir) = D:\GlobalDir\Version\AppName\Solution1\Version\ProjectA\
I want to copy the Output Dir contents to the following folder :
D:\GlobalDir\Version\AppName\Solution2\Project\Dependency
The base location "D:\GlobalDir\Version\AppName" needs to be fetched from one of the above macros. However, none of the macro values list only the parent location.
How do I extract only the base location for the post build copy command ?
Here is what you want to put in the project's Post-build event command line:
copy /Y "$(TargetDir)$(ProjectName).dll" "$(SolutionDir)lib\$(ProjectName).dll"
EDIT: Or if your target name is different than the Project Name.
copy /Y "$(TargetDir)$(TargetName).dll" "$(SolutionDir)lib\$(TargetName).dll"
If none of the TargetDir or other macros point to the right place, use the ".." directory to go backwards up the folder hierarchy.
ie. Use $(SolutionDir)\..\.. to get your base directory.
For list of all macros, see here:
http://msdn.microsoft.com/en-us/library/c02as0cs.aspx
You could try:
$(SolutionDir)..\..\
I think this is related, but I had a problem when building directly using msbuild command line (from a batch file) vs building from within VS.
Using something like the following:
<PostBuildEvent>
MOVE /Y "$(TargetDir)something.file1" "$(ProjectDir)something.file1"
start XCOPY /Y /R "$(SolutionDir)SomeConsoleApp\bin\$(ConfigurationName)\*" "$(ProjectDir)App_Data\Consoles\SomeConsoleApp\"
</PostBuildEvent>
(note: start XCOPY rather than XCOPY used to get around a permissions issue which prevented copying)
The macro $(SolutionDir) evaluated to ..\ when executing msbuild from a batchfile, which resulted in the XCOPY command failing. It otherwise worked fine when built from within Visual Studio. Confirmed using /verbosity:diagnostic to see the evaluated output.
Using the macro $(ProjectDir)..\ instead, which amounts to the same thing, worked fine and retained the full path in both build scenarios.
Would it not make sense to use msbuild directly? If you are doing this with every build, then you can add a msbuild task at the end? If you would just like to see if you can’t find another macro value that is not showed on the Visual Studio IDE, you could switch on the msbuild options to diagnostic and that will show you all of the variables that you could use, as well as their current value.
To switch this on in visual studio, go to Tools/Options then scroll down the tree view to the section called Projects and Solutions, expand that and click on Build and Run, at the right their is a drop down that specify the build output verbosity, setting that to diagnostic, will show you what other macro values you could use.
Because I don’t quite know to what level you would like to go, and how complex you want your build to be, this might give you some idea. I have recently been doing build scripts, that even execute SQL code as part of the build. If you would like some more help or even some sample build scripts, let me know, but if it is just a small process you want to run at the end of the build, the perhaps going the full msbuild script is a bit of over kill.
Hope it helps
Rihan
I solved my problem by reinstall VS and then download .Net Core (3.x and 2.x) sdk packages
Here is my post build script
Creates the custom path for my own. Including library and version.
Copies the .dll (target file)
Copies the *.md files.
script:
md c:\_References\$(ProjectName)\$(AssemblyVersion)
xcopy $(ProjectDir)$(OutDir)$(TargetFileName) c:\_References\$(ProjectName)\$(AssemblyVersion) /y
xcopy $(ProjectDir)*.md c:\_References\$(ProjectName)\$(AssemblyVersion) /y