Just recently uninstalled VS2017 RC and installed VS2017 RTM.
We have a Windows Service solution which includes a Setup project.
When I build this in Visual Studio 2017, somehow it's triggering something in the installer for Visual Studio 2013 (which we're still using), as I get this popup appearing:
It's fairly reproducible, but I have no idea where to start with this one.
Any ideas how to stop it happening?
It didn't happen before with the release candidate.
EDIT:
So, several VS2017 updates later, this problem had got a lot worse, as it was stopping me building the setup project completely. Previously I was able to click cancel as in my first screenshot, but at VS2017 v15.3.3, it wouldn't cancel, and if I let it run, it hung at:
So this forced my hand somewhat. I've accepted #PhilDW's answer as he led me straight to the main clue, but I'll also add an answer of my own with more detail.
As in PhilDW's answer, I checked the event log, and found this:
Detection of product '{9C593464-7F2F-37B3-89F8-7E894E3B09EA}', feature
'Visual_Studio_Professional_x86_enu', component
'{E3FF99AA-78B9-4A06-8A74-869E9F65E1FE}' failed. The resource
'C:\Windows\Microsoft.NET\Framework\URTInstallPath_GAC\' does not
exist.
A little Googling, and I found this MSDN blog entry:
Workaround
We are consistently seeing this issue caused by a missing directory,
C:\Windows\Microsoft.NET\Framework\URTInstall_GAC (or
%SystemRoot%\Microsoft.NET\Framework\URTInstall_GAC).
To work around this issue,
Open an elevated command prompt.
Type: mkdir %SystemRoot%\Microsoft.NET\Framework\URTInstall_GAC
Note that the folder name isn't the same as in my case. I didn't notice this initially, and creating the folder didn't cure the problem.
However when I created the actuall folder referenced by the event log message, the problem went away, and I can now build my setup project without messages about VS2013.
It's a repair of Visual Studio 2013 because Windows thinks the install is broken (registry entries or files not as in the original VS 2013 install). If you look in the Windows Event log, Application, there should be some MsiInstaller log entries that tell you the product (by ProductCode guid) and the broken component (by component guid and file or registry name). This might help identify what's going on, but not necessarily have a clue to a fix. If it's a setup project it might be a conflict with mergemodule Dlls or prerequisites, some of which come from the current SDK.
You don't say if you're letting the repair complete, in the case that it's just an isolated occurrence.
Related
I can't find any solution to this problem.
I had built my project in Release mode. When I changed to Debug mode and tried to rebuild the project, I got this error. And I KEEP getting this error no matter what I do.
I cleaned the project. No joy.
Restarted VS2019. No joy.
Deleted the bin and obj folders. No joy.
Switched back to Release mode. No joy.
The boss is waiting for this project and I can't build it because of this stupid unspecified error.
"...Another Xamarin operation is running..."
WHAT OPERATION???!!! How can I cancel that operation?
I rebooted the computer. No joy.
I own the paid version of Visual Studio Professional and this is not ok!!
Edit: I opened another version of the same project. This built ok.
Reopened the problem project and did not get the error.
Just wasted 2 hours on this
A workaround is :
Unload the Android project
Clean the solution
Reload the android project and restore it as Startup project
Now you can clean the solution and rebuild.
Unload the given project
Reload the given project
Clean the given project
Build
Solved.
Apart from restarting you may also need to delete bin and obj folders.
I had the same problem, but only on Android and not on UWP.
Edit: I opened another version of the same project on Android. This built not ok.
Reopened the problem project and did not get the error, so, problem solved.
Lots of thanks for your solution.
I started having this recently -- I use VS for Win connected to Mac to do the build for iOS project.
Let's face it, it's always wonky. But this got real bad today -- tried restarting VS, rebooting Mac, deleting bin/obj, etc.
Finally comment from OP made me think of something I didn't try -- shut down vs, delete the .vs folder, the bin/obj, and restart VS. I hate to delete the .vs cuz it resets stuff, including "reloading" my Android project, which I'm not currently working on.
Well, to early to say, but it worked once.
I was trying to run for the first time my localhost from Visual Studio 2019 and Windows asked me:
I accidentally pressed NO, so now I can't see my site.
I checked different suggestions offered here, in stack overflow, but didn't work.
I tried going to Add/Remove Programs and choosing the "Repair" option on IIS Express.
Also:
cd C:\Program Files (x86)\IIS Express
IisExpressAdminCmd.exe setupsslUrl -url:urlToYourSite -UseSelfSigned
None of them worked.
Hope anyone can give me a hand.
Thanks.
Solved:
I have deleted both, IIS Express 10 and Visual Studio and reinstall and that fixed the issue.
I did a lot of tests to try to restore your problem, but all failed. Even if I click no every time like you do, it will still pop up the next time I run it again. When it finally no longer pops up, the application can still run, but with http instead of https. Fortunately, I finally reproduced your problem and found the following solution.
In control panel->Uninstall or change a program, make IIS express repair. If repair doesn’t work. Just uninstall it and install it again.
Open Win+R ->enter %userprofile% -> Documents ->IIS Express, then delete all folders. Open your project in visual studio. Right click solution and clean it.
Both of these method worked while I tested. You can try them. If them still useless, please re-install visual studio.
I have a ASP Project running Visual Studio 2013 having very bad Performance while debuging/running the Project. The same Project running on a normal IIS Server is super fast with no Problems. Other Projects are running also super fast with no Problems (also on VS2013).
I have already tryed the following:
Delete All Breakpoints does nothing.
Debug or Release version, doesn't matter.
start without Debugging has the same problem.
Putting my project on a full IIS implementation on a web server runs it super fast with no problems.
Clean Solution, or deleting the .suo also do nothing
comment all the CodeBehind and the JavaScript
the solution with symbol loading from Visual Studio debugging/loading very slow also dont work.
Another often mentioned solution is to deactivate Intellitrace, but I don't found how to do that in VS2013 (the Intellitrace MenuItem in the Tools/Options Menu is missing)
There are many empty ScriptDocuments created while running, dont know if that has anything to do with the Problem.
Thanks for any Ideas!
This may sound strange, I had the same problem and tried all suggestions I found on the internet. The cause for me was I has a blank DVD in my drive. I found this by looking at where Visual Studio was trying to load the symbols from "my d drive (dvd)". After I ejected the blank DVD it was back to normal. This was very strange but just saying, check where VS is trying to load the symbols from in the output window. Hope this save someone from running round in circles.
After installing ASP.NET MVC 4 Beta, Visual Studio shows "Updating source control status" on the lower left side of the status area.
Any ideas? Seems a lot of stuff is broken after installing the beta. I am trying hard not uninstalling it.. :(
Issue is Nuget Manager. It installs templates for both ASP 4 and ASP 2.
Uninstalled Nuget Manager and then re-installed it (reopen VS Studio) and solutions come up in few seconds
I have the same exact problem! It seems to take forever to deal with TFS when opening a project.
I already uninstalled it once to verify (yes, it solved the problem). Now, I've re-installed and it came back with a vengeance. VS.NET locked up with loading my project :(
I'll post more if I get anywhere...
UPDATE: I waited longer and VS.NET wasn't locked up, it just took a really long time (5 minutes or so).
It seems that it's related to NuGet packages somehow, since my Source Control window has almost 1200 messages like this:
The item $/...[snip].../packages/AmplifyJS.1.0.0 already exists.
The item $/...[snip].../packages/AmplifyJS.1.0.0/AmplifyJS.1.0.0.nupkg already exists.
Every message in there is "already exists" for something in the NuGet "packages" folder
I'll keep you posted
UPDATE 2: I added a "Connect" bug. Go there and verify that you can see it too to get it more attention.
As Sonali pointed out, the issue is related to NuGet. On solution open, the NuGet package manager does a version control operation for every file in your "packages" directory. This issue should be fixed any day now in their 1.7 release by making it a one time bulk operation.
In the meantime, if you're using VS11 with TFS11, you can upgrade your workspace to a "local" workspace to eliminate the delay on solution open.
We were experiencing the same problem when opening projects...delays up to 10 minutes while the solution was loading. Our only solution after trying many suggested solutions via web searching, was to purge all deleted files for the project(s) in source control. Different solutions for different people seem to exist but if nothing else has worked, then maybe this helps.
I'm finding this problem in VS2013 Ultimate, but was not seeing the Nuget messages mentioned in other replies. The consistent message is "Updating source control status...", which can take upwards of 10 minutes to complete. It occurs at what seems like random intervals - I could be opening a solution, or typing out code, and UI lockup with the above message.
The solution that appears to be working for me now is to edit the devenv.exe.config file. Details can be found here.
Essentially you add one line to disable the default proxy. I hope this helps someone else.
I have a problem debugging a web forms application that is configured to use IIS for debugging, under Windows 7 and Visual Studio 2010. An example has just occurred, where I make a change to the code behind for a web form, save, and apparently rebuild before starting the app using F5.
The app starts, and I get an error message trying to do something in the app. I tell the debugger to break when an exception is thrown and try my task again, only to be told
The source file is different from when the module was built.
where the module is C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\root\9d7b45ca\11a98b19\assembly\dl3\5e6cf0b2\636409d4_dfeecb01\PerfixEMS_Admin.DLL
The physical folder for my test web site is set to the web application project's source folder, so I have always assumed that IIS will look in the bin folder for required assemblies, and these will be rebuilt as expected. Why is this not happening?
Cleaning the solution usually works for me.
Update
Given the high number (320) of projects I understand why Clean and Build won't work for you. You should however try it at least once to see if fixes things.
If it does fix your problem but doesn't last you'll need to do one of two things.
Clean just the one file
Delete the offending temp file. You probably won't be able to do this because with VS running since it may have a lock on the DLL. You may also have to stop IIS. You can use Process Explorer to look for the processes that have a lock.
Use a custom solution
Its unlikely that you're going to be modifing all 320 projects at the same time. Create a custom solution for just the projects you're working on. You'll still be able to step through any project you have the DLL and PDB for if you need to.
Which to do
Using a custom solution has its problems since you can no longer use project reference for projects not in your solution. This impacts your team's source control. You'll also have to make sure the DLL's and PDB's from outside your solution are in a stable location and you'll need a way to detect when thoes other projects have changes that you care about.
These problems can be overcome with a careful check-in process for Project changes and scripts that copy files and working with team members to figure out how to communicate changes.
On the other hand closing VS for every change or running Clean and build isn't really tennable either.
it may be a workaround, but I just need to see if it will work or not, then we may investigate more in the original case. but for now, try this:
1- publish this website to a different folder
2- open the newly published version from your preferred browser (ex: http://localhost/APP_NAME).
3- from VS, open "Debug" menu, choose "Attach to process..."
4- select the IIS worker process "w3wp.exe" and click "Attach".
(if you can't find it, make sure that the checkbox "show processes in all sessions" is checked)
5- start debugging your source code normally and let me know what happened, thanks.