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!
Related
I am running the build command like this:
set MSBuildParams=/m:16 /target:Rebuild
/property:Configuration=""Release"";Platform=""x64"" msbuild
%MSBuildParams% C:\path\to\the\sln\Solution.sln
I'm using the following msbuild version:
Microsoft (R) Build Engine version 14.0.25420.1
Solution.sln contains 2 projects,
let's say Project1 and Project2.
Project1 is set as the startup project.
After I build the Solution.sln using this setup, I would like to
rebuild it, but this time using Project2 as the startup project.
Is there a way to do that, without changing the Solution.sln?
What would be the best practice to accomplish that?
You could use the specific command line to build/rebuild the specific project using MSbuild like the following case.
specify project file of a solution using msbuild
But we have to change certain files if you want to change the start up project without using the VS IDE, since the setting was stored into the ".SUO" file.
Actually there is no setting in ".SLN" file for startup project even if you don't want to change it,
In addition, the start up project was the running project of the solution, maybe you don't have to change it:
https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/b6347dce-8449-4cbb-a606-7b19407a1026/how-do-i-set-the-startup-project-in-the-sln-file?forum=vcgeneral
I have configured subversion and Jenkins for Microsoft visual basic 6 project. Subversion contains more than 4000 files. Every time the build triggers, Jenkins compiles 4000 files, even if only few files have changed. I have written a batch script to compile visual basic 6 files which will search for *.vpb files in every folder. If *.vpb, present it will compile files present in that folder
#echo off
del "D:\buildfiles\log_file.txt"
for /r "D:\jenkins_setup\workspace\project" %%a in (*.vbp) do (
"C:\Program Files\microsoft visualstudio\vb98\vb6.exe" /make %%a /outdir
"D:\buildfiles" /out D:error_log.txt
echo %%a >> "D:\buildfiles\log_file.txt"
)
pasted this script in jenkins.
If files from few folders have changed, I want my script to compile only those files, not all 4000 files which are present in Jenkins workspace. To make this work, what else do I need to add to my script?
Jenkins itself doesn't compile. That process is handed to whatever build software you use. For example, if you have a C or C++ project, Jenkins would probably call make and pass to it a Makefile. If you have a Java project, Jenkins would call mvn, ant, or gradle with the correct POM or Build script. It would then be up to the individual build system to rebuild intelligently if so desired.
In your case, it's how Visual Basic itself is handling your Visual Basic Project files. I believe the build system compiles only those files whose last modification date and time is newer than their corresponding object file's modification date and time.
You should be able to get onto your Jenkins system, go to the workdirectory of that project and actually run the build from the command line and see what happens. Check the file dates. You might also want to set the Jenkins project to do an update only instead of a checkout.
I have a C# Visual Studio solution with about 15 projects. When I build the solution I want all DLL and EXE files for each project to go to a common folder (called Deploy).
The way I was thinking about doing it was, for each project's Post-build Event Command Line section put the following commands:
IF NOT EXIST $(SolutionDir)Deploy (
'If directory does not exist, create it
MKDIR $(SolutionDir)Deploy
) ELSE (
'Delete directory to make sure it's "clean"
RMDIR /F /S /Q $(SolutionDir)Deploy
MKDIR $(SolutionDir)Deploy
)
'Copy executable and required DLLs to Deploy directory
COPY /Y $(TargetPath) $(SolutionDir)Deploy
COPY /Y $(TargetDir)*.dll $(SolutionDir)Deploy
The problem with doing it this way, however, is I have 15 projects and would have put this in each individual project's post build event section and also, every time I add a new project, I would have to remember to do the same for it.
I checked the solution file properties and did not see a way to set a solution-wide post build event to copy all the files so I did a few Google searches.
One page said to use a C++ Makefile project. I added this type of project to my solution and clicked on the project properties page and found that there is a section under Configuration Properties->NMake with the following:
Build Command Line
Rebuild All Command Line
Clean Command Line
Using the Makefile project's Command Line option poses a similar problem to above. Many different commands to copy each of my 15 project's output files such as:
COPY /Y $(SolutionDir)Project1\bin\$(ConfigurationName)\*.exe $(SolutionDir)Deploy
COPY /Y $(SolutionDir)Project2\bin\$(ConfigurationName)\*.exe $(SolutionDir)Deploy
...
COPY /Y $(SolutionDir)Project15\bin\$(ConfigurationName)\*.exe $(SolutionDir)Deploy
There is another apparent problem with doing it this way. As you can see I took advantage of the $(SolutionDir) and $(ConfigurationName) macros but I had to hard-code each project name.
I didn't see any macros like $(AllProjects), $(AllProjectDirs), etc.
Also, it appears that command line commands for Makefile projects are for building, not post-build events, so I gave up on this idea altogether.
I then tried using a Visual Studio Installer project. After adding the project to my solution I right-clicked the project and saw that there was an Add->Project Output... option. This brought up a dialog allowing me to add one of my other project's Primary Output. I repeated this for each of my other projects and rebuilt.
What resulted was an .MSI file in the output folder. I then opened installer project properties and changed the Package files option to As loose uncompressed files and rebuilt. The output folder now contained all my project's EXE and DLL files!
Most people would be satisfied at this point and move on but I am the kind of person who likes to find the best way to do things.
There was one thing I didn't like about using the installer project option, the fact that, besides copying the files from all my projects, it also created an MSI file (which I don't need) and I didn't see any option tell it not to create one.
Can anyone recommend a another/better way to accomplish my goal of copying all project output files to a single folder?
Thank you.
P.S. I was thinking I could just make a batch file to search and copy all the EXE and DLL files to the Deploy folder but I would have to run the batch file outside of the Visual Studio IDE and also hard-code the configuration folder (Debug or Deploy).
Can't you just change the Output Directory of the C++ projects? See How to: Change the Build Output Directory.
On the menu bar, choose Project, Properties.
Expand the Configuration Properties node, and choose General.
Change the Output Directory value to the new output directory.
If you want both options, you can also create multiple configurations for your VS projects and solutions, similar to the standard "Debug" and "Release" ones. Create a new configuration from one of the existing ones, then change the output directory and save. Now you can just switch the configuration at the solution level to build into another directory. See this link for detailed steps:
How to: Create and Edit Configurations
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
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>