We're implementing Team Build and know we need to write MSBuild scripts to build our legacy VB 6 app. It's configured to use Binary Compatibility and we break Compatibility occassionally and we'd like our new automated build process to be able to Break Compatibility automatically.
Anyone know how to do this or if it's even possible?
Alternatively, I know that the break just changes the compatibility to No Compatibility, compiles, changes to Binary and recompiles. If anyone knows how to just change Compatibility from the command line this would also be helpful.
Regarding changing from Compatibility to No Compatibility, I've done things like this by editing the project file with Unix-style tools (sed, awk, and/or perl). Do not change the original project file, but instead generate a new/temporary project file, and build with that. Here's an example:
sed -e "s/CompatibleMode=0/CompatibleMode=2" <myProj.vbp >tmpProj.vbp
You can use this technique for other purposes, such as inserting a version number into the project file.
The /d switch allows you to replace project property values at compile time. Try
VB6 /MAKE c:\Some.vbp /outdir c:\somedir\ /d CompatibleMode="0"
This works:
VB6 /MAKE c:\Some.vbp /outdir c:\somedir\ /d CompatibleMode="0" CompatibleEXE32=""
I am not sure any of the solutions above work. we had same issues in our product. we had to write a vb project that (also functioned as an addin) to break compatibility and build the project. the vb project, reads the existing VB file, generates a new vbp file with project compatibility settings and new destination for the generated dll. the destination would be the same folder where the ref-dll resides. once the dll is built, the old dll's is removed and new red-dll one is renamed to match the old one. at the end of it, all temp files will be removed. the vb project has an exposed function that takes one parameter which is the vbp file. this could be run from a vb script. so essentially the command line argument would be
BuildRefDll.vbs <my.vbp>
vb6.exe /make <my.vbp>
Related
So I´m not very good at using batch-files, but I do need to use this. What I´m doing in the batchfile is following:
1 - Using tf.exe to get latest build from Main and updating the projectfiles.
2 - Compiling every file (.vbp) and then placing the exe / dlls in a folder called "Temp".
START VB6.exe /make "C:\Place1\Place2\development\Main\components\Place3\source\Place4\project11.vbp" /outdir C:\Temp\Place
This all works just fine, the "problem" I'm having with outdir, is that when I'm compiling every file, I do get correct major and minor version, but I want the folder structure, instead of it being "Temp", I´d like it in the batchfile to place it (mkdir) with the same major/minor version that is set in the project file.
So lets say I get latest project files, they are set to 1.0.0 I´d like the /outdir to be set to the same folder as version.
Thanks for reading!
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'm about to start doing some benchmarking/testing of our builds, and I'd like to drive the whole thing from a command line. I am aware of DevEnv but am not convinced it can do what I want.
If I could have a single file built within a single project, I'd be happy.
Can this be done?
The magical incantation is as follows. Note that this has only been tested with VS 2010 - I have heard this is the first version of Visual Studio with this capability:
The Incantation
<msbuild> <project> <settings> <file>
Where
msbuild is a path to MSBuild.exe. Usually this should be set up for you by the VS2010 bat file so the right one will end up in your PATH, but if not I found one at C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe
project is the path to the vcxproj file within which your source file resides.
settings include the following:
/p:Configuration="Debug" // or whatever your Configuration is
/p:Platform=x64 // or x86
/t:ClCompile // to specify specifically you're looking to compile the file
file is actually another setting:
/p:SelectedFiles="path_to_file"
Notes
For <project> I had to specify a project (vcxproj) file instead of a solution (sln) file. The sln I would have used has multiple projects within it, so there would have been extra work to go that route anyhow (if it can even be done).
For the /p:Platform=x64 setting, there are several environment variables that pivot on what platform you are targeting (x64 v. x86) so make sure you set those up properly via Visual Studio's vcvarsall.bat.
Regarding path_to_file in the SelectedFiles parameter, this path must be the path as specified in the project file. If the path does not match the path used in the project file to reference the source, it doesn't seem to work.
Since I write a command line program to check cpp files, and it need lib path and include path of those cpp files.
How can I get the include and lib path info from visual studio project? Our project uses property sheets to make up those information.
It is made up from 3 distinct sources:
Tools + Options, Projects and Solutions, VC++ Directories. In turn built up from several registry keys
the settings in your .vsprops project property sheets
the settings in your .vcproj project
The first part is the hardest, you can get it by running vc\vsvarsall.bat. The .vsprops and .vcproj files are XML, easy to parse.
If you just want to find out what the command line should look like then you can get it from the buildlog.htm file, produced when building from the IDE. Or you could use vcbuild.exe on the command line to build your project from the .vcproj file. Or you could build using devenv.exe /build.
Check out the Visual Studio project files - they're typically only XML files, so you should be able to extract out whatever you need from those, really. Just a matter of understanding and parsing your XML contents in the project file, really.
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