as I said in title, after update to v15.6.2, VS does not restart console (ASP.NET Core project type) when I do rebuild (CTRL + B), so I have to manually restart it (CTRL + F5) every time. (extremely sad, almost crying)
Before, I only need to run project once, when opened solution, and further rebuilds, just closes and then reopens console automagically.
Is this a VS bug? New feature? Maybe I've fat-fingered some project/build configuration?
It's almost an year since I've asked this and finally found where this settings hides :D
Anyway, for anyone who want to save his fingers, make sure to check/set true
Options -> Projects and Solutions -> ASP.NET Core -> Auto restart Kestrel server after build.
This will restart it auto-magically after each build, so you don't have to always press another key to start it.
P.S.
It didn't took me a year to search for this option, just accidentally found it ;)
Related
I used to deal with this when I was working with Adobe AfterEffects. It was (and maybe still is) so buggy that it could crash at any moment. So instead of fixing their buggy code-base their developers added a feature that would periodically auto-save all solution files into a separate (copy) folder. So after a crash you could recover some of your work. (Mine was set on auto-save every minute.)
So I've recently switched to using Visual Studio 2017 to develop my C++/MFC projects. (Before that I worked with somewhat older VS 2008 that used to crash very rarely.) But now VS2017 crashes pretty much every day. And if I forget to click save, it literally takes down last 10-15 minutes of my work, if not more.
I tried reporting this to Microsoft (back in summer of 2018, 6 months ago.) Some of my reports were either closed right away when they needed more proof and I didn't have time to deal with their laziness to read my entire post, but some that were accepted are still open and were never fixed. So I'm done submitting bug reports through that portal.
My only recourse at this point is to ask if there's an auto-save "feature" in VS2017, similar to what Adobe did to their AfterAffects?
Anyone wants to crash it right now? Here's just one bug. Create new project -> Visual C++ -> MFC/ATL project -> MFC Application. Then go to Resource View -> Add Resource -> Accelerator. Then click on "None" where I pointed with an arrow:
Is your VS2017 still running after that?
You can find a plugin in the market that does the job.
https://marketplace.visualstudio.com/items?itemName=fluffyerug.Autosave2017
"Auto Save File" extension has more installs and better reviews than the extension from fluffeyrug.
https://marketplace.visualstudio.com/items?itemName=HangjitRai.AutoSaveFile
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 have Windows 10, fully updated.
I downloaded and installed Visual Studio Community 2015 last week for the first time, (previously programmed in Code:blocks, still installed) and selected custom install to allow for C++ and Python programming.
Installation ran smoothly, but VS always fails on launch.
On first launch ever, it said it was setting things up for first startup; asked me for sign-in which I did, at which point it briefly showed something about my profile before saying 'An error occurred while starting for the first time. Please restart Microsoft Visual Studio'. Imgur images of all dialog boxes here, including parts of a processmonitor log I estimated to be around the general time of the error.
Closing and restarting several times didn't help.
Uninstalling and re-installing didn't help.
Rebooting didn't help.
And uninstalling, running Ccleaner's Cleaner and Registry Cleaner, rebooting computer and re-installing VS didn't help either.
Repairing the install from Programs also didn't help.
I managed to find the exact same error on Google Search for VS 2013 but the only solution was where one person got a completely new OS and re-installed VS on that.
I tried the other suggestions they had including running:
devenv.exe /safemode
devenv.exe /resetskippkgs
devenv.exe /resetuserdata
devenv.exe /installvstemplates
devenv.exe /resetsettings
the first 3 took me to the same sign-in screen. Regardless of signing-in or not, or running VS from the Administrator Profile or not, these option always give the same failed on first startup error.
Installvstemplates gives an error saying the operation could not be completed, but /resetsettings finally got me into VS.
That's about all it does though, I can go to the home page and access options/menu buttons, but signing-in makes it crash and reload again (but it does sign me in and take me to the home screen)
Signed-in/not and Administrator or not, VS crashes on opening a new .cpp file.
When I click Start a New Project I get "Error loading type library/DLL.(Exception from HRESULT: 0x80029C4A (TYPE_E_CANTLOADLIBRARY)). Closing VS and trying to open it normally from start menu still always throws the original error, despite working if I open it via /resetsettings.
I've also checked [HKEY_CLASSES_ROOT\CLSID{73B7DC00-F498-4ABD-AB79-D07AFD52F395}\InProcServer32] in Regedit and found it is apparently correct.
I also used devenv /log to generate an xml file of the process when I open it.
Just to mention I have .NET Framework 4.5-4.6 installed with VS as well.
Looking forward to any advice.
So, for anyone else getting the same problem, I haven't gotten any other advice, since this post.
If you're still having probs # this point the only real solution seems to be a clean install of your OS .
I can confirm it solved all my issues, with VS + some OS problems I wasn't aware of . I can only assume they might've been related, good luck.
I am having a strange problem with Code:Blocks. After writing C program i click on Build and run, it compiles in fraction of a second but then a new window opens and after around 12 seconds output appears on the window.
It takes this much time for even basic code like
#include<stdio.h>
int main()
{
printf("HELLO");
return 0;
}
Here are snapshots of what happens. As I am not allowed to post images{new to forum} I am posting links.
When I click on build and run, this window appears in no time
Then after around 10-12 seconds, this window appears. As you can see it says that execution time took 11 seconds.
Any idea why this is happening? How to fix it? I did no tweaks to code:blocks and settings are same as they come by default.
The problem was with antivirus. Whitlisting gcc,g++ and codeblocks solved the problem.
I faced the same issue. Later I found out that, its due to antivirus. I don't have any antivirus install in my PC. It was windows Virus and threats protection which was running all the time, which make execution slow.
What I did is, Go to Manage settings. After that you will found Exclusions somewhere. Go to exclusions. Then go to Add/remove exclusions.
There just add the folder where your .c or .cpp file is created. And then you are done.
Adding a youtube link which can be useful
[https://www.youtube.com/watch?v=OaQQsDIsc8o]
For any Avast user reading this
Open the interface
Go to settings
Go to general
Scroll down and you will find 'exclusion'
Enter the directory in which your CodeBlocks is installed. Also enter the directory in which you have saved your project.
What is the setting of Settings -> Compiler -> your compiler -> Build options -> Number of processors?
For your CPU it should be 8-12. This option will help you if you have many files. If you have 1 file it doesn't matter.
p.s. you've not mentioned what compiler you're using, so this might be the cause.
p.p.s. gcc on windows is slower than the linux version, 2x and more times slower...
Even without antivirus, Windows Defender(in Windows 11) was slowing it down for me.
When I excluded the folder, it started to work faster for me.
Steps for excluding the folder from Windows Defender scan in Windows 11 (10 might be same I guess):
Open up Windows Security app.
go to Virus and threat protection.
Under Virus and threat protection settings, click Manage settings.
Scroll to last, under Exclusion click on Add or remove exclusions.
Click yes for the permission.
there you can add the file/folder to exclude from.
Now build and run your code, it should run faster. If not then sorry your problem seems to bigger than this solution.
I use ClipX on my computer to keep a clipboard history, and it works just fine. After I upgraded to MSVC2012, however, it no longer picks up any of the copies I do inside Visual Studio. It seems that Visual Studio is somehow catching the CTRL+C before ClipX is, or something? Anyway, I prefer ClipX to MS's implementation, so I was hoping there was some way to just completely disable that functionality
Are you running the latest version of ClipX available? Even though it's labeled "Beta", version 1.0.3.9 works well, and if you're on Win7 x64 there's a 64-bit version available, which is what I run. I'm not running Windows 8 or 8.1 yet so cannot comment on whether it works with those.
I'm running VS2013, and I cannot reproduce your problem exactly, but... I do have a similar problem (and solution):
I run VS as administrator (I change the properties of devenv.exe to always run as admin) for interop with IIS, among other reasons. ClipX still picks up the values from copies/cuts, but when I try to use the ClipX popup list to paste a value other than the current clipboard entry, it doesn't actually paste into Visual Studio. ClipX does move the item to the top of the list, and a second Ctrl+V does then paste the value into VS, but it's very annoying.
The solution is to run ClipX as administrator also. Since running a program as admin at startup/login is only possible through Task Scheduler, this is a bit of a pain to set up, but once I've set it up, ClipX has no problem interacting with VS (or any other program I run as admin).
If you are running VS as admin you could try running ClipX as admin (just right-click it in the Start menu) and see if it fixes your problem. If so, then worry about the Task Scheduler part. If it doesn't fix your problem, then well, it was worth a shot.