SUMMARIZE THE PROBLEM:
I'm using Visual Studio 2015 for some project and what I'm trying to do is to run a batch file which is going to open an app(whatever app). The problem is that the VS2015 is going to get stuck in the build process until my app is going to be close.
The batch is working perfectly fine. You could try this just with a batch something like:
start notepad.exe
Or whatever you want, it doesn't really matter what's the application you are going to open here.
WHAT I'VE TRIED:
I've tried already some alternatives like...
Run the bat from the post-build event with "call", "start" or with none of them.
I've added "exit 0" on the end of the file(batch)
Also, I've tried to create 2 batch files. One was the original one and the second one was calling the first one. So I've added the second one at the post-build event. Nothing changes, of course.
WHAT I AM TRYING TO OBTAIN:
On the end, all that I'm trying to obtain is just a batch with is going to open an application after the build/rebuild of the project is done without getting stuck somewhere there.
It's going to stay in this "Build" process even though the build is "Build Succeed"
Unfortunately I believe all processes spun off by the build have to be joined and returned successfully for VS to consider the build a success. Instead, is it possible in your use-case to attach the batch file to the execution step of your project? In the project settings you can modify the command line arguments to spin off your batch file before executing your project executable. Is there any issues with this approach?
I found this too, would this help: Visual Studio post build events stuck waiting for executable to finish before running app in debug mode
I'm just starting to code C++ with the VS Code.
Is it possible to set default configurations (json files) for each project?
Right now I have to manually create these files and configure them for each program.
Thanks, Roie
It seems to be not possible currently. You can monitor this issue from the vscode Github: Shared configuration (tasks/settings) #1435
Global tasks in a task.json file are still on the agenda (to get
parity with launch.json). However it is a matter of priorities when
they will come. (Oct 26, 2018)
So you would have to build something yourself like a python or bash script that automatically generates the json files for you.
During a long compilation with Visual Studio 2005 (version 8.0.50727.762), I sometimes get the following error in several files in some project:
fatal error C1033: cannot open program database 'v:\temp\apprtctest\win32\release\vc80.pdb'
(The file mentioned is either vc80.pdb or vc80.idb in the project's temp dir.)
The next build of the same project succeeds. There is no other Visual Studio open that might access the same files.
This is a serious problem because it makes nightly compilation impossible.
It is possible that an antivirus or a similar program is touching the pdb file on write - an antivirus is the most likely suspect in this scenario. I'm afraid that I can only give you some general pointers, based on my past experience in setting nightly builds in our shop. Some of these may sound trivial, but I'm including them for the sake of completion.
First and foremost: make sure you start up with a clean slate. That is, force-delete the output directory of the build before you start your nightly.
If you have an antivirus, antispyware or other such programs on your nightly machine, consider removing them. If that's not an option, add your obj folder to the exclusion list of the program.
(optional) Consider using tools such as VCBuild or MSBuild as part of your nightly. I think it's better to use MSBuild if you're on a multicore machine. We use IncrediBuild for nightlies and MSBuild for releases, and never encountered the problem you describe.
If nothing else works, you can schedule a watchdog script a few hours after the build starts and check its status; if the build fails, the watchdog should restart it. This is an ugly hack, but it's better than nothing.
We've seen this a lot at my site too. This explanation, from Peter Kaufmann, seems to be the most plausible based on our setup:
When building a solution in Visual Studio 2005, you get errors like fatal error C1033: cannot open program database 'xxx\debug\vc80.pdb'. However, when running the build for a second time, it usually succeeds.
Reason: It's possible that two projects in the solution are writing their outputs to the same directory (e.g. 'xxx\debug'). If the maximum number of parallel project builds setting in Tools - Options, Projects and Solutions - Bild and Run is set to a value greater than 1, this means that two compiler threads could be trying to access the same files simultaneously, resulting in a file sharing conflict.
Solution: Check your project's settings and make sure no two projects are using the same directory for output, target or any kind of intermediate files. Or set the maximum number of parallel project builds setting to 1 for a quick workaround. I experienced this very problem while using the VS project files that came with the CLAPACK library.
UPDATE: There is a chance that Tortoise SVN accesses 'vc80.pdb', even if the file is not under versioning control, which could also result in the error described above (thanks to Liana for reporting this). However, I cannot confirm this, as I couldn't reproduce the problem after making sure different output directories are used for all projects.
Switch the debug info to C7 format instead of using the PDB.
Project Options -> C/C++ -> General -> Debug Information Format and set it to C7.
This generally happens when your previous attempts at debugging have not killed the debugger fully.
In Task manager look for a process called vcjit, kill it and try again.
Worst option restart visual studio, this should solve your problem.
I had this problem today and it turned out to be non-ansi characters in the path to the pdb that caused it.
I'm using windows through vmware, and my project was in a shared location: \vmware-host\Shared Folders\project
When I moved it to \Users\julian\project it resolved the issue.
I just ran into this problem. Visual studio was complaining about not being able to open vc100.pdb. I looked for open file handles to this file using procexp and found out that the process mspdbsrv had an open file handle to it. Killing this process fixed the issue and I was able to compile.
Try right click the excutable file of VS....and Properties->Compatibility-> Tick "Run this program in compatibilty mode for:" OFF........
I had a similar problem while working on a project which I had located in my Dropbox folder. I found that it would throw this error when the little "syncing" icon was going on the Dropbox icon in the system tray, since Dropbox was accessing the files to upload them to their server. When I waited to build until Dropbox finished syncing, it worked every time.
I have same problem C1033: cannot open program database,
Scenario
I have two dll's parent.dll and child.dll.I just attached child.dll project with visual studio debugger at the same time i am trying to build the parent.dll project,produces error C1033: cannot open program database
Solution
Stop debugging and kill the process attached with the debugger.Rebuild the project
This happens to me consistently if I Ctrl+Break to cancel a build (vs2015). There's some process that isn't shut down properly. I went on a rampage "End Tasking" ms/vs related processes (look for duplicates) and my build worked again. A restart would probably work too. As would moving to gnu binutils.
Annoyingly unlocker tools don't report any processes locking the file, windows doesn't let me delete the .pdb but I can rename it. My guess is two processes jump in at the same time during a build.
Are you using LinqToSql at all? Perhaps it is similar to the odd error I will experience occasionally as I asked in this question: What causes Visual Studio to fail to load an assembly incorrectly?
I changed my intermediate directory from:
%TEMP%\$(ProjectName)\$(Platform)\$(Configuration)\
to
C:\temp\$(ProjectName)\$(Platform)\$(Configuration)\
It works now. NO idea why.
In my case the problem was Google Drive: I forgot that the project was under a synced folder and G Drive probably locked that file. Pausing the sync didn't help since the error was throwed anyway.
Moving the project folder to another location not synced by Google Drive solved my issue.
Just to mention, at the beginning I thought it was my anti-virus, since when examinating the file using procexp it showed that the file was used by one of my anti-virus process. Excluding the folder project from my anti-virus scan didn't help in my case.
the simplest solution is "build one more time":
BuildConsole abc.sln /rebuild /cfg="release|Win32"
if %errorlevel% neq 0 (
BuildConsole abc.sln /cfg="release|Win32"
if %errorlevel% neq 0 (
rem process error
exit 1
)
)
I just ran into this problem and Google led me here. For me, it was Google Drive syncing my project files while I'm trying to run. Pausing Google Drive sync temporarily solved it, but I'd rather there was a way for Google Drive to keep its hands off while Visual Studio is doing its stuff. If anyone knows how I can configure that, please let me know
I generated .coverage file using the Performance Tools in VS2010. I can follow all steps to get the .coverage file in command line.
but i have VS2010 Professional version, so that i cannot open the .coverage file and see the coverage inside VS2010 (or can I do so?). Is there a way to see the results another way, using freeware etc... ?
For instance is there a way to get the Microsoft.VisualStudio.Coverage.Analysis.dll and have it working fully in VS2010 PRO ?
Thanks
The Question
Is it possible to build the Intellisense database for a solution (C++) at the command line?
The Context
I work on a fairly large C++ codebase. The code takes a while to compile so I set up a local nightly automated build that I can grab any time I want to start a new task. I would like to create the Intellisense database for the solutions of the codebase during this nightly build. We are using Visual Studio 2013.
According to this answer on MSDN, it is (sadly) not possible:
It is not possible to create this file without running VS, it is not a
scenario the team designed/planned for.
Ryan