I would like to setup an automatic software distribution process, preferably from Microsoft Visual Studio, which builds my projects in all the different configurations and platforms, and packages all the created objects in a predefined folder tree structure.
The software distribution packages would be for Windows libraries and WDM driver projects written in C/C++. Each library has several different configurations (i.e. Windows 7 Release, Windows XP Release, MT/MD runtime compilation flags) for different platforms (i.e. x86 and x64). A similar thing is with the drivers. Without any automatic process to create a software distribution package, it's necessary to build all the different configurations for each platform and then copy the created objects to a predefined folder structure and then zip the created folder giving it a release name and version. This process is quite time consuming and error prone. Therefore, my goal is to automate this process using a clean a nice solution.
I've been researching about this for a few weeks already and have actually implemented a few different solutions. However non of the solutions I implemented until now is flawless whatsoever. Hence since this should be a problem that I guess many developers have already encountered, I would like to hear different opinions on what would be a nice and efficient way to do it.
Up until now I've tried the following:
A batch script and a Makefile to be used by NMAKE. This is not so good because it makes difficult to set the same build parameters that are set on the visual studio project.
Implemented a "deploy" target task (editing the .vcsproj files) which calls MSBuild of the project for each configuration/platform and copies the generated files to a distribution directory. This has the advantage that I can start the deploy activity from within visual studio but it also produces several environment variables problems, specially when building windows drivers.
Any ideas or suggested solutions will be appreciated.
Thanks in advance.
Zion
If you haven't already, add a post-build step for each lib and driver which copies the built files into your specific tree and also zips them.
If you haven't already, create one Visual Studio solution (.sln file) which builds all these projects at once.
If you haven't already, set up Build configuration using the Build | Configuration Manager dialog. Now from the IDE, you should be able to specify a specific configuration and do a Build | Rebuild Solution and make sure all the projects are successfully built.
From the command-line, you can now automate #3 by opening a Visual Studio command line prompt (which sets up the environment variables appropriately). Start devenv.exe with appropriate command-line parameters.
Related
I have created a GUI and Database for my company. I am trying to alpha test the program. I made the program so that everyone would place it on their C drive so that the file paths would stay consistent. When I email the zip folder to everyone it adds an extra folder that is causing errors to the file path (I believe the error occurs during extraction?). Does anyone know a good way to prevent this from happening? Thanks!
Although "xcopy deployment" is a valid method to deploy programs, it can come with complications, as you have discovered. Instead, you can create an actual installer program which is much more versatile.
For a lead-in on making an installer you can read Create MSI installer in Visual Studio 2017.
Make sure that the program uses locations as given in the Environment.SpecialFolder Enumeration so that it is automatically adapted for any (properly-configured) Windows installation.
Other installers are available, e.g. Inno Setup, which may offer simpler or more detailed configuration of some options like replacing or keeping older files, or installing prerequisites like a required framework version.
I just finished coding my c program in visual studio (VS) and what I had done is just drag the compiled .exe file out of the folder to run it on other computers, except on other computers for that to work I guess I need VS since it says the MSVCR110D.dll is missing which is from VS. So how can I run my program on other computers that don't have VS?
You can use IExpress which is used for distributing self-contained installation packages. It is there in every windows machine preinstalled. Using this utility you can make the executable .exe which will be incorporated with dependent dlls. You can see Step by step guide, to see how to use it.
Follow these steps
https://msdn.microsoft.com/en-us/library/3w7axy17.aspx
In your output window it will show you where you can find the exe file, usually something like "ProjectName/Debug/Release/"
If you have added any external libraries you will have to copy any DLL files in that folder with the exe (You can combine them with some applications if needed)
You will also have to make sure that you have the correct version of the .NET Framework on the PC that you are trying to run your program on
I am trying to automate a build process for a C# (vs2008) solution.
The build script is written in a Batch script which I want to change. We use Clearcase as the CM system. I have searched some tools such as MSBUILD, NANT.
Any suggestions which is a better solution like a sample script in MSBUILD and NANT?
I have not seen any sites where MSBUILD and NANT is documented well or any good tutorial about each task description.
Where I can learn MSBUILD or NANT either of them and write script from scratch?
There is a third way which I prefer. You can also use devenv.com. It's faster than NANT, doesn't require NANT bins and works on any machine with VS installed. You also avoid possible errors with MSBUILD (http://support.microsoft.com/kb/964125).
Just use %path_to_devenv.com%\devenv.com "%path_to_sln" /<buildoption> BuildConfig
In my case it's
%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\devenv.com "C:\Projects\XYZ\xyz.sln" /rebuild Debug
This way it's guaranteed that your project will be build exactly the same way as it's being built in Visual Studio.
EDIT:
Now that we know how how much there is to do, I'll try to give an outline how you can setup the whole system for automated build controll.
Set up your repository (I hope this is already done - tell me if not)
Install and set up Jenkins (https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins) including users, ClearCase-Credentials, plug-ins for ClearCase, MSBuild, etc. (all of them can be found in the Jenkins plug-in interface) - this is the biggest peace of work
Create and set up a new project in the jenkins interface (name, working directory, etc.)
Tell jenkins to use source code management (e.g. subversion module), enter the ClearCase repos to use, set the desired behavior of the source code management
Set a build trigger (I recommend checking the source code management each minute: * * * * *)
Add a build step and select "Build a Visual Studio project or solution using MSBuild" - this option should appear after installation of the MSBuild plugin (https://wiki.jenkins-ci.org/display/JENKINS/MSBuild+Plugin)
Set the path to the .sln file (you have checked it out from your repository)
Add more optional arguments if desired (eg /p:Configuration=Release or Debug or whatever http://msdn.microsoft.com/en-us/library/vstudio/ms164311%28v=vs.110%29.aspx)
Play around untill it works
Btw., I recommend to put all external dlls into your repository.
For Linux packages, specifically RPMs with stored checksums, we always can check two things: the contents of package is ok and the installation from this package is ok. When someone modifies parts of the installation he shouldn't, we can see it by running rpm -Vp my-precious-package. In our busyness it is not only recommended, but obligatory to provide our packages with tools for this purpose and for Linux these are just simple bash scripts.
Now I have to do something similar for Windows. Basically what I want is to provide some batch file by running which one can get assured, the installation is the same as it meant to be in the package. I'm using InstallShield for packaging, and yet it has some great visual tools, I still haven't found a way to verify package checksums in the command line.
Is it even possible, or should I reinvent the wheel writing my own checking utils?
Take a look at MakeCat and SignTool from Microsoft, both in SDK
http://msdn.microsoft.com/en-us/library/windows/desktop/aa386967%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa387764%28v=vs.85%29.aspx
Windows Installer has a feature called resiliency that supports auto repair of products and there are ways to call it for self checks only. (This is assuming by InstallShield you mean Windows Installer based projects.)
Here's a couple links to read to get you started:
INFO: Description of Resiliency in Windows Installer
Resiliency
Application Resiliency: Unlock the Hidden Features of Windows Installer
MsiProvideComponent function (See dwInstallMode flags)
This also assumes all files are key files. Companion files are not managed by the installer. Also changes performed by custom actions outside of the installer aren't managed.
Suppose you have some source code that comes from the unix world. This source consists of a few files which will create a library and a lot of small .c files (say 20 or so) that are compiled into command-line tools, each with their own main() function, that will use the library.
On unixy systems you can use a makefile to do this easily but the most naive transformation to the windows / Visual Studio world involves making a separate project for each tool which, although it works, is a lot of work to set up and synchronize and more difficult to navigate at both the filesystem and project/solution level. I've thought about using different configurations where all but one .c file are excluded from the build but that would make building all the tools at once impossible.
Is there a nice way of building all the tools from a single "thing" (project, msbuild file, etc.)?
I'm really not interested in using cygwin's gcc/mingw or NAnt. I'd like to stick with the standard Windows toolchain as much as possible.
You don't HAVE to use visual studio to compile code. You can make your own batch file or Powershell script that simply calls the compiler on your source, just like a makefile.
So I've been looking into this for a while now and the solutions all leave much to be desired.
You can...
Create a lot of small projects by hand.
Use MSBuild and deal with its steep learning curve.
Use a build tool that does not integrate well with Visual Studio, like GNU make.
You can't even make a project template like you can with .NET projects! Well, you can make a wizard if you want to wade through the docs on doing that I suppose. Personally, I have decided to go with the "many small projects" solution and just deal with it. It turns out it can be less horrible than I had thought, though it still sucks. Here's what I did in Visual Studio 2008:
Create your first Win32 command line tool project, get all your settings down for all platforms and make sure it works under all circumstances. This is going to be your "template" so you don't want to edit it after you've made 20 copies.
(optional) I set up my paths in the visual studio project files so that everything is built in the project directory, then I have a post-build step copy just the dll/exe/pdb files I need to $(SolutionDir)$(OutDir). That way you can jump into a single directory to test all your tools and/or wrap them up for a binary distribution. VS2008 seems to be insane and drops output folders all over the place, with the default locations of Win32 and x64 output differing. Spending a few minutes to ensure that all platforms are consistent will pay off later.
Clean up your template. Get rid of any user settings files and compiler output.
Copy and paste your project as many times as you need. One project per tool.
Rename each copied project folder and project file to a new tool name. Open up the project file in a text editor like Notepad++. If you have a simple, 1-file project you'll need to change the project name at two places at the beginning of the file and the source code file name(s) at the end of the file. You shouldn't need to touch the configuration stuff in the middle.
You will also need to change the GUID for the project. Pop open guidgen.exe (in the SDK bin directory) and use the last radio button setting. Copy and paste a new GUID into each project file at the top. If you have dependencies, there will be one or more GUIDs at the bottom of the file near the source code. Do NOT change them as they are the GUIDs from the dependencies and have to match!
Go into Visual Studio, open up your main solution and add your tool projects.
Go into the configuration manager and make sure that everything is correct for all supported platforms, then test your build.
It's not beautiful, but it works and it's very much worth the setup time to be able to control your builds from the GUI. Hopefully VS2010 will be better about this, but I'm not too hopeful. It looks like MS is giving a lot more love to the .NET community than the C/C++ community these days.
If you have a makefile you can use a 'makefile' project in Visual Studio (which in misnamed - it simply allows you to specify custom build/debug commands), and use it to invoke GNU make.
You will need to change the makefile to use the VC++ command line tools instead of cc or gcc or whatever it uses, but often these are specified by macros at the top of the makefile.
If the makefile uses other Unix specific commands (such as rm), you may need to make modifications, or create bath files to map commands to Windows equivalents. Another option is to install any necessary tools from GNUWin32 to make it work.
If the build is very complex or involves configure scripts, then you have a harder task. You could generate the makefile from a configure script using MSYS/MinGW, and then modify it as above to make it work with VC++.
Makefile projects will not be as tightly integrated in Visual Studio however. All the build management is down to you and the makefile.
If you're really using Visual Studio, I would suggest creating a project for each tool, and adding these projects to a single solution. From Visual Studio, it's easy to build a complete solution all at once, and MSBuild knows how to build .sln files as well.
msbuild myslnfile.sln
or even:
msbuild
... will build your solution.