I have a Visual Studio solution which I'm trying to build using the Incredibuild tool. Two of the projects in the solution work in tandem - the first project (we'll call it "Project A") builds an executable (foo.exe) which can parse a data file in the second ("Project B") to generate some header files.
Obviously there is a dependency on Project A defined in Project B. If I use Incredibuild's Rebuild Project option on Project B, it correctly builds Project A and foo.exe is successfully built. Project B has a custom build tool file which should cause foo.exe to be ran with a command-line argument to the file it's supposed to parse. However, trying to launch foo.exe in this way always returns an error:
CustomBuild:
Running Foo
'path to executable\foo.exe' is not recognized as an internal or
external command, operable program or batch file.
C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5):
error MSB6006: "cmd.exe" exited with code 9009.
Interestingly, if I then use Incredibuild to build only Project B (i.e. using the Build Project option), everything is ok - it correctly picks foo.exe from the location it was built to on the previous, failed, build. This makes me think that the path, at least, must be ok.
Can anyone suggest why the executable cannot be ran as part of the rebuild? Is it a timing issue, e.g. Project B commences before foo.exe is known to the file system??
It all works under Visual Studio's regular (re)build. It's just the Incredibuild rebuild which fails. Note that I'm doing all of this through the Visual Studio IDE, not from a command line.
Edit: this is the freebie version of Incredibuild that I'm using (the one which comes with Visual Studio), so all of the build is on the local machine.
I contacted the Xoreax technical support about this in the end and they told me that this is a "rare but known issue that is related to one of our extra accelerating features".
Their first suggestion was writing an executable which simply sleeps "for a few milliseconds" and having that run as part of the custom build tool post-link. This did indeed solve the immediate problem, but the solution I'm building has numerous similar problems and adding this delay in everywhere quickly became tedious and didn't always work. It felt like a fudge anyhow.
So I asked if this behaviour can be toggled to off, and indeed it can. In Visual Studio the Incredibuild menu has an Agent Settings option, and from the invoked dialog's Visual Studio Builds|Advanced page it's a simple case of unchecking the Enhance throughput using out-of-order tasks spawning option.
Case closed.
There are options how to offload or intercept custom tools during your build process. Try to look onto "c:\program files (x86)\IncrediBuild\Samples"
Related
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'm using Visual Studio 2010 to build a program in C that can operate on a PostgreSQL database.
Everything is fine in VS, no compile errors, everything looks good.
When I click to debug and run, the code compiles, but then I get a pop up that says:
The program can't start because libpq.dll is missing from your computer
I've installed PostgreSQL and added the folder containing all the necessary files to my include and linker paths, but to no avail.
I cannot figure out why I am still getting this message?
Any suggestions?
The answer's surprisingly simple.
The issue you're seeing comes from the compiled application not being able to find the PostgreSQL libraries. The libpq.lib is used to compile the application, and it links to the DLL at run-time. You can either add it to your system wide path, or bundle the DLL with your application. (I'd add it on the development machine, and bundle the redistributable for a installer package.)
To include it in your path try:
Right click on "My Computer" and select Properties
Then Click on "Advanced System Settings".
Click the "Environment Variables" button at the bottom of the dialog box.
It will pop up a dialog with a group box labeled "System Variables". Find the one in the list box that has a Variable name of "Path".
Now, add the path of the PostgreSQL library folder to the path with a ";" separator.
Now logout or reboot. It's imperative that you at least log out of Windows and log back in for the Visual Studio debugger to pickup the additional executable module paths (that Path variable). Ideally, rebooting sends the new system path to all applications in the system at boot time.
If the Path variable has "C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem" in it, you would add ";C:\Program Files\PostgreSQL\libraries" to make it look like "C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Program Files\PostgreSQL\libraries".
Be aware that your path will be really long in most cases. Just add it to the end.
Good luck!
I have Win10 64 bit and this worked for me.
Get portable version of HeidiSQL and copy libpg.dll from the archive to the HeidiSQL installation folder on your computer.
Works like a charm.
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.
In a Visual Studio 2010 solution, I have 2 projects:
Project A which is a dll project
Project B which is an executable project and depends on project A (configured through the solution project dependencies properties)
When I add new APIs in project A declared with __declspec(dllexport) specified and call them from project B.
If I simply "Build" the project B, it turns out that project A is built then project B but the linker does not find the new APIs and report them as unresolved external symbols.
Now if I "Rebuild" the project B, the solution is fully rebuilt and I do not have unresolved symbol linker errors.
Any idea what could cause the builder to not find the new symbols using a simple Build action and how to fix this?
Pretty hard to explain this with the info you provided. It clearly strongly suggests a build order problem, even though you documented that A gets built first.
You may have a problem with the parallel build feature available in VS. If it doesn't see any dependency between projects then it allows projects to build concurrently, taking advantage of your machine having multiple cpu cores. You can see A starting building but B starts building right away as well. Indicated with a numbered messages in the Output window, preceded with 1> and 2>.
If there actually is a dependency then it becomes a race. If B progresses to the link stage before A is done linking then it will certainly have trouble. But that is typically announced by it complaining it cannot find the import library for the DLL project. It finding an old version of A.lib that is missing some identifiers would be an unusual corner case. Things do however get interesting when it finds A.lib while it is being written. Which does explain what you observed.
Best thing to do is to ensure that VS knows there is a dependency without relying on it figuring it out by itself. It is not very good at figuring this out for C or C++ projects. Right-click your B project in the Solution explorer window and click "Project dependencies". Tick the A project. Now it will no longer build concurrently, B won't start building until A is done. Which is essentially what you did by hand to work around the problem.
If you still have trouble then you'll need to suspect other programs on your machine, the kind that mess with files. Anti-malware software is always on the top of the list of troublemakers like that. Avast is especially notorious for giving VS a hard time.
I have a question does it happens every time? It should not. Build command links, create binaries, find resources depending on the existing resource. No, if you change any resource like library, images form designs etc. Then you need to rebuild (clean+build).
To make a project build before another project build. You have to add dependency by this:
Right click to solution>properties.
Go to Project Dependencies > Select the project and tick the dependent project.
Finally right click to your project B select Set as StartUp Project.
This will force your project to build sequentially.
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.