Visual Studio 2008 has been very stable for months on my computer.
This morning when I double-click on any .xaml file to open it, or even click on the tab of an already opened .xaml file, Visual Studio says "initializing toolbar" in the status bar and then 20 seconds later fully closes the whole application without any error message.
Other files (e.g. .cs class files) I can open fine.
Has anyone experience this or know what I could check/change to be able to use Visual Studio to edit .xaml files again?
MORE INFO: I can also create a new project and create and edit .xaml files fine.
MORE INFO: I can edit .xaml files in other modules (projects) fine.
MORE INFO: Everytime it crashes, this event is registered:
.NET Runtime version 2.0.50727.3053 - Fatal Error in executable module (72555E00) (80131506).
(odd since I have .NET framework 3.5 installed)
MORE INFO: It is only in one module (project) that .xaml files cause Visual Studio to crash. Even creating a new UserControl in that module crashes Visual Studio.
I get this occasionally (with .xaml and .resx files) and find that if I delete the solutions .suo file things work fine again.
[The suo file just contains per user settings like recently opened files etc so it's nothing important and will just be recreated when you next open the solution.]
I've been getting the same issue whenever I try to access project settings for a C# project.
Found additional information about this:
Here: http://blog.fryhard.com/archive/2008/11/26/visual-studio-2008-closes-at-build-outlook-2007-add-in.aspx
And here: http://social.msdn.microsoft.com/Forums/en-US/vsto/thread/99e124d0-c5d7-49c0-b1dd-71328f9a6571/
Apparently it's a bug in the core CLR engine that causes the entire CLR to crash if certain types of assemblies are loaded in a certain order.
Most of the time it appears to be directly related to the Visual Studio add-in called PowerCommands - uninstalling PowerCommands will make the problem go away.
And (we hope) it's supposed to be fixed for .Net 4.
This sounds very similar to the issue I had when I first installed VS 2008. Unfortunately, after hours of research, I ended up reinstalling the IDE (with my fingers crossed). No problems since then, but it's obviously not the most enjoyable way to solve the problem.
What is likely happening here is that one of the controls referenced directly on indirectly in your designer is stack overflowing during the designer process. Because the designer is hosted in process a stack overflow by one of the components will take down the designer and VS.
Try attaching a debugger to VS, break on first chance StackOverflow Exceptions and open the designer.
Related
I downloaded and installed Telerik's WinForms components demo and removed it later. However, the VS extension that adds the Telerik menu in the main menu system was not removed correctly. After deinstallation, my VS started to display about 10 message boxes at startup telling that Telerik assemblies like Telerik.WinControls.VSPackage.2018.1.115.1 cannot be loaded. Here is the corresponding part of the VS startup log (the ActivityLog.xml file viewed in the browser):
I asked Telerik's support about this problem and posted a message on their community forums, but nobody has answered yet - even after several days.
Having no answer, I tried to find all remnants of the problem extension in VS folders and the system registry and cleaned all what I found, but VS is still trying to load some "tails" of this non-existing Telerik extension.
Is there a way to trace and clear all remnants of a VS extension left by its uninstaller (manually or automatically using a tool)?
I got an answer to my question from the Telerik team:
Visual Studio 2017 uses its own private registry to store this king of
information -
C:\Users\UserName\AppData\Local\Microsoft\VisualStudio\15.0_8ab640ac\privateregistry.bin.
Removing this file should resolve the issue on your side. The file
will be auto-generated by Visual Studio once it is launched.
Note: You if choose to delete the file your personal preferences
regarding the Visual Studio IDE environment will be reset to the
default ones and you may need to set up them in the Options dialog.
Frankly speaking, I could not try what they suggested. I suddenly discovered that my instance of VS no longer tries to load any Telerik assembly at startup. I think it happened after upgrading to the latest version 15.5.7, which was done with the administrator privileges. I earlier launched VS with admin rights several times, and as I saw, some problem Telerik entries (but not all) were cleared by VS automatically in this mode. It seems, VS can heal itself in the admin and/or upgrade mode.
I try to edit an axml file in Visual Studio, because drag and drop doesn't work in Xamarin Studio. But when I open my axml file, it's loading forever.
I've been waiting for more than 10 minutes, but it is still loading. When I restart VS I can open the axml file without any problems.
The same applies for all my other axml files (in other projects).
Does anyone knows how to fix this?
I'm using the newest stable version(cycle 8) of Xamarin btw.
EDIT:
I'm using Visual Studio Community 2015 Version 14.0.25425.01 Update 3 and I've got all the latest updates installed.
More detailed explanation:
I open my project in Visual Studio
I open my foo_bar.axml file
I switch from the Designer tab to the Source tab
I remove the android:background="blablabla" attribute
I switch from the Source tab to the Designer tab
The Designer tab is loading forever
AND
I open my project in Visual Studio
I open my foo_bar.axml file
I make some changes
I close the foo_bar.axml file
I reopen the foo_bar.axml file
the foo_bar.axml file is loading forever
NOTE:
The problem doesn't happen when I change the android:text="blablabla" attribute at step 4 and when I change some other attributes it also doesn't happen, so it is specific to just some attributes.
According to a forumer at Xamarin Forums, it has something to do with Cycle 8's AXML Designer not being able to render using the newest API.
But even in Cycle 8 when I choose to compile under Android 6.0 instead of 7.0 in the project's properties, the designer is still wonky as it is. Switch between "Designer" and "Source" on one .axml file and the designer still loads until Harambe cometh.
Therefore, your best bet is to downgrade Xamarin Studio to Cycle 7, and you can finally get the AXML Designer as working as before.
Until Cycle 9 or an incremental update/hotfix of Cycle 8 comes about, this is the way to go for now.
You can download and install the previous cycle in the link below:
https://store.xamarin.com/account/my/subscription/downloads#cycle7
For your own interest, you can read more about the aforementioned forum thread below:
https://forums.xamarin.com/discussion/77992/axml-layout-designer-inside-visual-studio-keeps-loading-forever
This happened to me also. Then I realised I hadn't opened Visual Studio in Admin mode. After I did, everything was fine.
Open the visual studio as admin and it loads perfectly. All the best.
I get a blank security warning popup window when trying to open a website, in Visual Studio 2015 Community Edition. It worked on my other computer in the same environment.
I moves the files to a new fresh computer and I get this window.
Here's a screenshot:
Nothing is clickable, even what where the buttons should be. Visual Studio is just frozen, can't even close the IDE nor the popup window. It doesn't happen to Web Projects, only websites.
Any idea how to solve this?
I got the same issue. Just fixed it. In my case it was entity ".tt" files fault. I guess for some reason VS 2015 does not recognize ".tt" extension. I've just deleted these files and run website (not web application) successfully
The .tt files are needed if using Entity Framework.
Here is my workaround that worked in two cases of the blank security warning. Rename the files with .tt extension to .tt.old.
Open the project (it will not compile, so don't try)
Save and close the project
Rename the .tt.old files back to their original names
Open the project again, this time the warning will have content and will be clickable.
I'm building a project in Visual Studio 2010 and the build fails because it cannot copy the assemblyname.dll file from obj to bin folder. The exact error message is:
Error 7
Unable to copy file "obj\Debug\AssemblyName.dll" to "bin\AssemblyName.dll". The requested operation cannot be performed on a file with a user-mapped section open.
I think this is because the previous file in bin-folder is not accessible. When I try to delete the file manually, I get an error "The action can't be completed because the file is open in another program". If I try to see what application locks the file with Unlocker, I don't get any results (No Locking handle found).
If I restart Visual Studio, the error goes away but happens again after a build or two. Goes without saying that this is seriously slowing me down. Any advice how to start solving this?
VIsual Studio 2012 on Windows 8. I was receiving the same error message on my project. Restarting Visual Studio or cleaning the obj folder manually did not help. Finally I closed all open files (Windows -> Close All Documents) and the problem went away.
This behavior was due to a newly installed Visual Studio extension called Visual Studio Achievements (http://visualstudiogallery.msdn.microsoft.com/bc7a433b-b594-48d4-bba2-a2f24774d02f)
I noticed that the .pdb file was locked by FxCop (using Unlocker) and I think that the Achievements -extension uses it. After disabling the extension I've no longer got the error mentioned above.
This bug has been fixed in recent versions of the extension (>1.7). It was released as a beta, btw...
This behavior of VS happen very often even on my computer (and on computers of my coworkers).
In my experience it happen more frequently when:
I have some form opened in design when i compile
I stop the execution od the application by pressing the "stop" button
in VS instead of exiting the application
So, closing the form in design before compile, and exiting the application instead of stopping it, somewhat mitigate the issue... but it still happen :-|
My computer is Win 7 x64 SP1 with VS 2010 SP1, 8Gb ram, and no swap file
Platform: Windows 8 Pro, Visual Studio 2012
I found that I receive this error when I am accessing the folder in Windows Explorer.
I was creating PDF documents with Visual Studio 2012. To review the sample document I would right click in Solution Explorer and use Open Folder in File Explorer.
On Windows 7 I would get a SYSTEM.IO error if the actual PDF document was open in Adobe Reader which is expected. With Windows 8 I found that I receive the above error if I have the folder open. I suspect there is a conflict with the Windows 8 preview.
If I close the folder and run the program it works fine.
Check if you open the dll in visual studio.
I open the dll in visual studio and this error happen!!
I often use command line tools to do source control updates of files and projects that I have loaded into Visual Studio 2010. With previous releases when I did this I could force Visual Studio to notice and load the changes by doing a Save All. This doesn't seem to work in Visual Studio 2010.
I do have 'Detect when a file is changed outside the environment' checked in the Options window, but if I sit and wait it takes minutes or longer for the changes to be noticed.
How can I force 2010 to notice the changes in loaded source files and projects?
You can reforce reloading a project by unloading and loading the project.
Right-click the project and select Unload Project, then, when the project is unloaded right-click again and select Reload Project.
Note that this requires that all modified files in the project either be saved or the changes in the file be discarded.
It sounds like this could be the same problem that I experienced here. VS 2010 doesn't seem to pick up on file changes made outside the IDE (like if you add a file to the file system, and then click refresh in Visual Studio you don't see the new file, I experienced this on C++ projects).
You can refer here for the MS case, they claim they have fixed the problem in "the next VS release", which I assume would mean the first service pack for VS 2010.
Win7 shouldn't be a pre-requisite, though its possible an earlier edition (pre-SP1) of Visual Studio didn't work it. Upgrade always works, for reference the track changes option also needs to be turned on.