Does anyone know if VB6 IDE has the ability to run pre-build events prior to making and compiling the code (this is for creating a .vb file from a template file for subversion revision numbers to be compiled into the code using SubWCRev.exe).
Thanks
There is no method to do this from the IDE. My company built a utility (in VB6) to do our automated build process including steps like you mention (updating version numbers, etc).
The essential trick is that you can run VB6.exe from the command line to compile projects. To see a list of all the option just goto the VB6 directory and type
VB6 /?
A list of all the command line options will appear.
This is what we use for our build utility.
VB6 /Make <project name> /out <errorlog filename>
We copy our project to a temporary project files and alter it using check boxes and parameters files. For example we can choose to compile everything as binary compatible or project compatible. The VB6 project files are easy to manipulate as they are just text. There are any number of things you can do if you write your own build utility.
We use Visual Build Pro to do this. It has built-in support for updating the version numbers of VB6 projects. Our project group includes ~7 ActiveX projects which is really painful to build within VB in the correct order, so we just always use Visual Build Pro because it automatically handles building the projects in the right order based on their dependencies.
There is some support in NAnt (or possibly NAnt.Contrib) for building vb6 projects. NAnt can then handle all of the pre/post build events. Just be prepared for some tweaking.
Related
To automate C++ code quality analysis in our company, I've been asked to integrate Cppcheck tool with our SonarQube server (through the C++ Community plugin).
For the C++ part of our main product, in Visual Studio, we have a dozen of solutions, with almost a hundred of projects within each solution.
We use standard inherited property page macros like $(SolutionDir) and $(ProjectDir), and define our own custom (user-defined) macros as well (via Property Manager).
I'm currently writing Windows command line batch scripts to perform static code analysis separately on each solution. The idea is to run Cppcheck with an option like --project="solution_name.sln" and then run SonarQube Scanner to parse the generated XML output.
But there's a problem. It seems that Cppcheck doesn't recognize these $(SolutionDir) macros during include path resolution. (When run with --check-config option, it complains about missing include files.)
Unfortunately it turns out I even cannot supply additional include paths for a solution because the -I and --includes-file options are ignored when --project is specified.
How is Cppcheck supposed to be used with Visual Studio projects in an automated environment? I'm talking about command line interface (to be used on server side), not about interactive plugins (as used locally on developers' machines).
One possible way would be to create a Python script to preprocess the hundreds of project (*.vcxproj) files, replacing all these macros with real paths (each time after checking out from SVN and before executing Cppcheck). Or is there a proper way to make Cppcheck recognize Visual Studio macros?
Yes the --project is supposed to work. It's just that --project is a very new feature.
I would like to have a simple solution so I can reproduce easily.. Could you create some simple solution with such configuration? no real code is needed. I think a cpp file with just a #include and then an empty header might be enough. Configure it so that Visual Studio finds the header but Cppcheck doesn't.
Please attach it to the ticket orbitcowboy created.
Is it possible that I can just compile all CPP files under a project and without linking etc. the project?
The only way I know to do this is by specify the /c switch when you compile the code. Unfortunately, this option is not available from within the Visual Studio development environment, so you'll need to build your code on the command line by calling cl.exe directly. To make things easy on yourself, use the Visual Studio Command Prompt to do so.
Not sure if it's possible to get MSBuild to do this, the documentation is unclear whether the limitation is Visual Studio itself or if it's a limitation of MSBuild. I haven't actually tried for myself.
Alternatively, you can build individual source files from within the IDE by pressing Ctrl+F7 (at least, assuming the default C++ development settings). If that fails, it's also available as the "Compile" option located in the "Build" menu.
I'm not sure whether this will do what you need, but may be worth a try: create a project for an executable (rather than a library) and include all cpp files in it. Add a main() function that just returns zero. Set the C++ optimisation option to 'optimise references' (/OPT:REF). This may just compile all the cpp files but effectively ignore them during the link stage since none of them are referenced by the application.
You don't say why you need to do this - is it because linking takes a huge amount of time?
I am trying to build MSIs in a TFS Build by shelling out to DEVENV.exe (since MSBUILD does not support VSPROJs). In any case, my first installer project builds fine, the second one fails. If I reverse the order, same thing happends (i.e. the error does not follow the project). Looking at the output, I get the following errors:
Deserializing the project state for project '[MyProject].dbproj'
[MyProject].dbproj : error : Error HRESULT E_FAIL has been returned from a call to a COM component.
Also, I get:
Package 'Microsoft.VisualStudio.TestTools.TestCaseManagement.QualityToolsPackage, Microsoft.VisualStudio.QualityTools.TestCaseManagement, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' failed to load
It looks as though the first build tries to serialize the DB project (and it says it succeeds, but there is no DBML file anywhere). Then the second build tries to deserialize the DB project and fails.
I've tried resetting env settings (using the /resetusersettings flag) as well as using the /resetskippkgs flag. Nothing works.
Any ideas?
When you shell out to DevEnv, are you building that specific project (.vdproj file), or are you building the solution? It sounds like VS is trying to open the solution on the build machine and the database and test project systems aren't present.
Have you considered porting your setup project to WiX?
Start simple. Unless you're well versed in the problem you're trying to solve it's usually best to try it "by hand" before getting it running as part of a TFS build. RDP into the build server and try running the necessary commands at the command line and see what happens. You can even go simpler than that and RDP into the build machine and load Visual Studio and build it.
Bottom line is that if you can't get it to build within Visual Studio or at the command line by calling devenv.exe it won't work as part of the team build.
I am using the below Exec task to do precisely what you are doing as part of a TFS build. So I know this works. Your platform and configuration may vary depending on what you're building. The nice thing about this is that you'll have a log file at C:\Temp\MSIBuildOutputLog.txt that you can analyze for additional errors and information.
<Exec Command=""C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe" "$(PathToSolution)\solution.sln" /Build "Release|Mixed Platforms" /out "C:\Temp\MSIBuildOutputLog.txt"" />
One important thing to note... There is a bug in VS2010 which causes MSI generation to fail when you try to run it at the command line using devenv.exe. This took me days to find and figure out, but you need this hotfix. Worked like a charm...
http://archive.msdn.microsoft.com/KB2286556
Actually it's the deployment projects that don't support msbuild. FWIW, this is all deprecated in the next release of Visual Studio so you might want to start looking at InstallShield Limited Edition and/or Windows Installer XML now before spending too much time on dead end, broken technology. Both of these alternatives have proper MSBuild support aswell as many other improvements.
It would be perhaps better and quicker to adopt WIX (Windows Installer XML) which is the technology MS now recommends to use within VS/MSBuild/TFSBuild environment to crate MSIs.
It is relatively easy to setup and integrate within your VS Solutions. It uses XML based files to describe your MSIs and uses these files to create your MSIs when you compile.
I would start by downloading Wix from http://wix.codeplex.com/
Once installed you would be able to use the VS2010 integration of Wix based projects to create MSIs. To get started quickly simply add a new Wix project to your solution and reference the projects whose output you wish to combine into an MSI. Next you can run a tool called "Heat" which is included with Wix toolkit to generate the XML files by scanning your projects.
Once you have these XML files, add them to your Wix project and compile.
Where can I find the build script -all the list of tools used to build and link the assemlies like al.exe etc.-that BUILDS, REBUILDS the visual-Studio solutions?
MSBuild (the build engine for Visual Studio) uses a model where the tool(s) used for an action are dictated by the project file being built. Thus your list of tools will vary based on the types of projects you are building. The easiest way to find out the list of tools being used for a build of any given solution would be to turn on a more detailed logging level (detailed or diag) for MSBuild via Tools->Options->Projects & Solutions->Build & Run in Visual Studio and then parse/investigate the build output for an indication of the tools currently invoked by the Build Targets.
As Nick Nieslanik has said in his answer, the actual toolset will vary based on the project type (and target programming language), maybe even the selected .NET framework version.
To have single view on all definitions, properties, targets, etc. used by MSBuild, you could generate and review a fully preprocessed project file (only available with MSBuild 4.0 or newer).
From msbuild.exe /? output:
/preprocess[:file]
Creates a single, aggregated project file by
inlining all the files that would be imported during a
build, with their boundaries marked. This can be
useful for figuring out what files are being imported
and from where, and what they will contribute to
the build. By default the output is written to
the console window. If the path to an output file
is provided that will be used instead.
(Short form: /pp)
Example:
/pp:out.txt
Example:
msbuild.exe myproj.csproj /pp:out.xml
In this case out.xml is basically a self-contained file that has all the Import-ed project files inline so you can easily search and browse them.
In each project (in this case a c# csproj) file is a link to the msbuild used by msbuild/visual studio to build.
e.g. <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
This target links to the internal files used.
I am looking for best practice in building multiple visual basic projects(all dll's).We have multiple projects, and our final deliverable will be a dll.Now, one project uses 2 other projects, and another refers to another project.Should projects reference the vbp files, or the dll? If they reference vbp files, how to build all the projects?
After some years with VB6, our projects tended to be structured like this:
All project source (project and source) organized under the source folder.
\project\source
\project\source\project1\
\project\source\project2\
...
All binaries (.dll and .exe) in one bin folder.
\project\bin\
All .dll set as binary compatible with resulting file in the single bin diretory.
After initial build to make the binarycomptible stable, every non breaking build would
be done by using a simple command file build.cmd placed in the folder above the source folder, maybe like this:
"c:\Program Files\Microsoft Visual Studio\VB98\VB6.EXE" /M .\source\project1\proj1.vbp
"c:\Program Files\Microsoft Visual Studio\VB98\VB6.EXE" /M .\source\project2\proj2.vbp
"c:\Program Files\Microsoft Visual Studio\VB98\VB6.EXE" /M .\source\project3\proj3.vbp
del .\\bin\\*.exp
del .\\bin\\*.lib
The build order must be in the order of dependance.
Whenever a breaking change occured, the dependant VB project must be refrenced to the new binary.
Without breaking changes, the build.cmd usually did the job.
Unless you are specifically managing the type libraries externally from VB, you should use project references. If you reference the files, and you modify the public interface in various ways VB will generate new id's for various pieces in the typelibrary which will result in type mismatch errors.
You can use the Preserve Compatability settings to help alleviate this. Make sure your using at least project level (If your doing COM+ then you'll want binary the one based on an already compiled version of the dll)
As for compiling, you can compile a solution file (been a long time since I even had Vb6 installed but I think they were .vbg files).
Back in the day we used Visual Build, and also Visual Make which supported compiling the solution files.
You compile each project separately starting at the lowest level and working your way up the chain.
The big problem of builds with VB6 generally goes back to compatibility issues. The worst case compatibility problems the fix goes something likes this
Build A (with A being the one all the others reference)
Copy A into the compatibility directory
Build B that reference A
Copy B into the compatibility directory
Build C that references B and A
Copy C into the compatibility directory.
and so on.
This is because the typelibs of the COM DLL uses INCLUDE to add in the typelibs of the projects they reference. You can see the Type Libs of a VB6 COM DLL by using the OLE View tool that comes with Visual Studio 6.0.
Many times adding methods or properties will cause the DLL to fail to compile because MS Method of setting up the Typelibs renders them not binary compatible. This fails when the addition is otherwise permitted under the rules of binary compatibility.
The solution that works 90% of the time is to always put the newest version of the DLLs being reference in the compatibility directory.
Once you have a good set you can have a automated builder use it to build the project automatically.
Note that this issues occurs only when you add something that other DLLs reference and they need to maintain binary compatibility.
You need a system of making sure everybody has the correct set of compatibility DLLs to build against.