Related
I just installed GPS on Windows 10
In order to make browsing to my source file folder less annoying, I tried adding it as a bookmark in the folder browser accessed from the new project window.
When I right clicked on the folder and added it as a bookmark, the window blanked and froze. Now, every time I open the folder browser, it blanks and freezes. I uninstalled and reinstalled GPS, but it didn't help.
I can open projects, since it uses the default windows folder browser, and I can create projects if I type the folder path manually.
How can I fix GPS to make the folder browser not freeze?
I resolved the issue with help from Adacore customer support by removing the AppData\local\gtk-3.0\bookmarks file.
I'm getting the following error when trying to open any .cs file in my solution.
I've tried 1) restarting Visual Studio, 2) restarting computer, 3) delete all obj folders, 4) delete all .vs files and folders and still I can't open any files.
Same error message if I double click on the file in solution explorer or use F7.
The files do exist.
I've also tried disabling resharper in case it was that causing the issues, but it doesn't help.
I've also tried navigating to classes using Ctrl+T, entering class name and selecting the class. No error messages, but nothing loads.
This is the error I got when I tried to open an old solution: Cannot access a disposed object. Object name: 'WorkspaceContext'. I found the solution from Refat Eid's blog.
You just need to open the following directory and delete the content there:
%LocalAppData%\Microsoft\Team Foundation\7.0\Cache
Depending on your Visual Studio, you may have a different version number in your %LocalAppData%\Microsoft\Team Foundation. If you are not sure, copy the content to a temp folder first.
Other answers, either upgrading or reinstalling, basically serve the same purpose.
The problem here was that my solution folder was inside my OneDrive folder, which was doing automatic syncing with my OneDrive account.
Moving the solution folders out of the one drive folder made the errors go away.
I have the same issue but in Visual Studio 2019 Community Edition latest update which is Version 16.7.2.
After the update, all of my solutions that was bound in Azure Devops were experiencing problems when I try to checkin with the same error message as OP.
So, I deleted the folder but instead of:
%LocalAppData%\Microsoft\Team Foundation\7.0\Cache
I deleted this instead:
%LocalAppData%\Microsoft\Team Foundation\8.0\Cache
Then re-open my solution and it will rebind automatically after this message box:
In case it didn't rebind. Try to re-open your solution via Team Explorer -> Source Control Explorer and double click the solution directly on the Source Control Explorer.
In my case it was solved by simply restarting the visual studio.
I solved this problem, by re-downloading the vs installer (i apparently deleted my old copy), and telling it to run an update as well.
This is insane. Why should OneDrive synchronization cause this problem?
My Windows 10 system just installed a bunch of new updates today (4/11/2018). Immediately after those updates were installed I was unable to open any of my C# files in VS 2017 (error: Cannot access disposed object). All of these files opened without problem prior to today's updates.
Moving the projects off OneDrive solved the problem, as did opening the files in a previous version of VS (I tried VS 2015).
All of my VS projects are stored on OneDrive, with copies on my local drive. OneDrive claims that all my files are up to date, so I don't understand how this can be related to OneDrive synchronization.
Has anyone else suddenly run into this problem?
In my case, I have the solution file and its folder under OneDrive sync folder. Right click OneDrive system tray and click Settings. Under the Settings tab, uncheck Save space and download files as you use them checkbox (Files On-Demand)
I had the same issue, however after I upgraded to the latest version of Visual Studio 2017 (15.6.7), the error message disappeared, so I could open all files in the solution again. Hope this helps.
In my case this was due to deleting solution configurations which were not immediately saved, just saving all and restarting Visual Studio solved the problem.
In my VS2019. Closed VS. Disable Sync of One Drive Files, and reload project. Problem gone! It definitely seems somewhat related to OneDrive. Even though in my case all files were Sync'ed still pausing it and re-opening VS resolved. It could have been just restart of VS...
I had the same error. My solution is not stored in onedrive, but locally.
the full error message was :
error performing rename. cannot access a disposed object. object name invisibleEditor
the error happened when I renamed first the file from the solution-explorer window then clikced yes, which normally changes the class name as well, however this did not happen.
then when i tried to change the class name the error was thrown.
I restarted VS 2019 Enterprise 16.11.3 few times but that did not help.
I resolved this by:
undoing the renaming of the file in the solution explorer
deleting the .vs folder in my solution directory
deleting all the bin and obj folders in on my projects within then solution.
the renaming was then successful.
the error stack was :
System.ObjectDisposedException : Cannot access a disposed object.
Object name: 'InvisibleEditor'.
at Microsoft.VisualStudio.LanguageServices.Implementation.ProjectSystem.InvisibleEditor.get_TextBuffer()
at Microsoft.VisualStudio.LanguageServices.Implementation.ProjectSystem.VisualStudioWorkspaceImpl.ApplyTextDocumentChange(DocumentId documentId,SourceText newText)
at Microsoft.VisualStudio.LanguageServices.Implementation.ProjectSystem.VisualStudioWorkspaceImpl.ApplyDocumentTextChanged(DocumentId documentId,SourceText newText)
at Microsoft.CodeAnalysis.Workspace.ApplyChangedDocument(ProjectChanges projectChanges,DocumentId documentId)
at Microsoft.CodeAnalysis.Workspace.ApplyProjectChanges(ProjectChanges projectChanges)
at Microsoft.CodeAnalysis.Workspace.TryApplyChanges(Solution newSolution,IProgressTracker progressTracker)
at Microsoft.VisualStudio.LanguageServices.Implementation.ProjectSystem.VisualStudioWorkspaceImpl.TryApplyChanges(Solution newSolution,IProgressTracker progressTracker)
at Microsoft.CodeAnalysis.Workspace.TryApplyChanges(Solution newSolution)
at Microsoft.CodeAnalysis.Editor.Implementation.InlineRename.InlineRenameSession.ApplyRename(Solution newSolution,IWaitContext waitContext)
at Microsoft.CodeAnalysis.Editor.Implementation.InlineRename.InlineRenameSession.CommitCore(IWaitContext waitContext,Boolean previewChanges)
at Microsoft.CodeAnalysis.Editor.Implementation.InlineRename.InlineRenameSession.<>c__DisplayClass78_0.b__0(IWaitContext waitContext)
at Microsoft.VisualStudio.LanguageServices.Implementation.Utilities.VisualStudioWaitIndicator.Wait(String title,String message,Boolean allowCancel,Boolean showProgress,Action`1 action)
at Microsoft.CodeAnalysis.Editor.Implementation.InlineRename.InlineRenameSession.CommitWorker(Boolean previewChanges)
at Microsoft.CodeAnalysis.Editor.Implementation.InlineRename.Dashboard.Commit()
at Microsoft.VisualStudio.Telemetry.WindowsErrorReporting.WatsonReport.GetClrWatsonExceptionInfo(Exception exceptionObject)
We just did a move from storing all files locally to a network drive. Problem is that is where my VS projects are also stored now. (No versioning system yet, working on that.) I know I heard of problems with doing this in the past, but never heard of a work-around. Is there a work around?
So my VS is installed locally. The files are on a network drive. How can I get this to work?
EDIT: I know what SHOULD be done, but is there a band-aid I can put on right now to fix this and maintain the network drive?
EDIT 2: I am sure I am not understanding something, but Bob King has the right idea. I'll work with the lead web developer when he gets back into the office to figure out a temporary solution until we get some sort of version control setup. Thanks for the ideas.
While we do use Source Control, we do also run all our projects from Network Drives (not shared directories, private directories on network drives). The network drives are backed up nightly, and also use Volume Shadow Copy, so if you need to revert to something before it made it's way to SC, then you can.
To get projects to run correctly with the right permission, follow these steps.
Basically, you've just got to map the shared directory to a drive, and then grant permission, based on that Url, to all code. Say you map to "N:\", then use "N:\*" as your Url pattern. It isn't obvious you need to wildcard, but you do.
The question is rather generic so I'll give an answer to one issue I was facing.
I run Visual Studio 2010 using a Parallels virtual machine on my Mac while keeping all my projects on the mac side via a network share. Visual Studio however wouldn't load the projects assembly files from there. Trying to set the rights using "caspol" alone didn't help in my case.
What finally worked for me to allow Visual Studio to load assemblies from a network share was to edit the file
"C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe.config" (assuming a default installation).
in the xml "<runtime>" section you have to add
<loadFromRemoteSources enabled="true"/>
You may have to change the permissions on that file to allow write access. Save the file. Restart Visual Studio.
In the interests of actually answering the question, I copied this comment from jcarle.com:
Trusting Network Shares with Visual Studio 2010 / .NET Framework v4.0
January 20, 2011, 4:10 pm
If you are like me and you store all your code on a server, you will have likely learned about trusting a network share using CasPol.exe. However, when moving from Visual Studio 2008 (.NET Framework 2.0/3.0/3.5) over to Visual Studio 2010 (.NET Framework 4.0), you may find yourself scratching your head.
If you are used to using the Visual Studio Command Prompt to quickly get to CasPol, you may find that some of your projects will not seem to respect your new FullTrust settings. The reason is that, unless you are carefully paying attention, the Visual Studio Command Prompt defaults to adding the .NET Framework 4.0 folder to its path. If your project is still running under .NET Framework 2.0/3.0/3.5, it will require setting CasPol for those versions as well. Just a note, I have also personally had more success with using 1 as a code group instead of 1.2.
To trust a network share for all versions of the .NET Framework, simply call CasPol for each version using the full path as below:
C:\Windows\Microsoft.NET\Framework\v2.0.50727\CasPol -m -ag 1 -url file://YourSharePath* FullTrust
C:\Windows\Microsoft.NET\Framework\v4.0.30319\CasPol -m -ag 1 -url file://YourSharePath* FullTrust
I would not recommend doing that if you have (or even if you don't have) multiple people who are working on the projects. You're just asking for trouble.
If you're the only one working on it, on the other hand, you'll avoid much of the trouble. Performance is going to out the window, though. As far as how to get it to work, you just open the solution file from VS. You'll likely run into security issues, but can correct that using CASPOL. As I said, though, performance is going to be terrible. Again, not recommended at all.
Do yourself and your team a favor and install SVN or some other form of source control and put the code in there ASAP.
EDIT: I'll partially retract my comments. Bob King explains below the reason they run VS projects from a network drive and it makes sense. I would say unless you're doing it for a specific reason like Bob, stay away from it. Otherwise, get your ducks in a row before setting up such a development environment.
So I was having a similar issue. Visual Studio wouldn't recognize a network location I had mapped for a drive letter for anything. The funny thing is, it worked for a day. I set up my project and began working on it and had no issues. Then, I shut down and the next day nothing works. I couldn't read/write files in code, output my executables or anything. My project is local but my output was intended to be thrown up on the network.
Anyways, the problem is probably about the administrator context but one way to fix it which I found while digging around online is to get Visual Studio to browse to the drive in question some how. There are plenty of ways to do this but VS will magically be able to recognize mapped drive letters. My solution is to go the the Debug Output Location in the Project Properties, click browse and go to my previously made output location on my network drive and Voila!!!
I wanted to put this up because I spent half a day trying to figure this out and figured it might save someone else some time. Thanks much and good luck!!!
Erik
I understand this is an older thread, but this was the best thread I found when looking to solve a similar issue I had visual studio 2013 on a virtual box (using Win 8.1) and the code on the host machine (Win 7). Although I could open the solution, I could not compile. All of the other answers on this relate to older software, so I am adding this answer to update this frequently found question with the solution that worked for me.
Here's what I did; Made a registry entry to be able to use a UNC path as the current directory.
WARNING: Using Registry Editor incorrectly can cause serious, system-wide problems that may require you to reinstall Windows NT to correct them. Microsoft cannot guarantee that any problems resulting from the use of Registry Editor can be solved. Use this tool at your own risk.
Under the registry path:
HKEY_CURRENT_USER
\Software
\Microsoft
\Command Processor
add the value DisableUNCCheck REG_DWORD and set the value to 0 x 1 (Hex).
WARNING: If you enable this feature and start a Console that has a current directory of an UNC name, start applications from that Console, and then close the Console, it could cause problems in the applications started from that Console.
Found this information at link: http://support.microsoft.com/kb/156276
How about we rephrase this into a question that everyone can answer? I have the exact same problem as the initial poster.
I have a copy of VB 2008 (recently upgraded from VB6). If I store my solutions on the backed up network drive, then it won't run a single thing ever. It gives "partially trusted caller" errors for accessing a module, even when "allowpartiallytrustedcallers" is set in the assembly. If I store the files on my (not backed up) C:, then it will run wonderfully, until I put it on the share drive for everyone to use, and I'm back to my same problem.
This isn't a big request. I just want to be able to put a solution and executable on the share drive and run it without an absurd amount of nonsense about security. I shouldn't have to cram all my work into form files.
-Edit: I found the problem with why it was ignoring the AllowPartialllyTrustedCallers command. I'm trying to reference ADODB, which doesn't allow partially trusted. So, no network executable can access a database? What does Microsoft have against intranets anyway?
I was facing the same issue just recently so this answer is more for the sake of keeping track of my own knowledge. Anyway, should soumeone find it useful, below is the issue and the solution.
Issue:
NET 4.0 projects, SVN repo, checkout folders are on local drives, referenced assemblies are build by build server and available on a network drive. Visual studio on W7 is is able to add the reference but unable to build projects.
Solution:
Since NET 4.0 does not automatically provide a sandbox anymore for network assemblies, you have to make those full-trusted via machine.config update. http://msdn.microsoft.com/en-us/library/dd409252.aspx
I had a similar problem with opening Visual Studio projects on a network drive, and I fixed it by creating a symbolic link on my local C:\ drive that points to the UNC directory
e.g.
mklink /D "C:\Users\Self\Documents" "\\domain.net\users\self\My Documents"
then you can just open the project using the C:\Users\Self\Documents\ path, instead of the UNC path
(You have to be careful, because Visual Studio will automatically redirect you to the '\\domain.net..' path if you double click the symlink when you're browsing for the project. I had to copy paste the 'C:\Users\' path to get it to open with the drive letter path)
Don't do it. If you have source control (versioning), you do not want your files on a network drive. It totally bypasses all you want to achieve by using source control, because once your files are on a network drive, anyone can modify them .... even while you're currently building your project. Ka-boooom!
PS: this sounds like a typical case of over-engineering to me.
Are you having any specific problems?
If you allow more than one person to open the solution, your first problem will be that the .NCB file (Intellisense) will be locked exclusively and only one user will be able to browse the class tree. And of course you have the potential for one user's changes to overwrite the other user's changes.
You should be warned that some feature in Visual Studio will refuse to work with network drive.
For example, mdf file of SQL Express user instance must be located in local drive.
For another example, if you use UNC path, you have to make sure they are short enought.
i found this helpful while trying use vc11 with parallels which run on mac:
http://social.msdn.microsoft.com/Forums/en-US/toolsforwinapps/thread/2ffdcb01-c511-4961-834b-afd5f2fbb8e1, and specifically:
1) You can switch from local debugging to remote debugging and set the machine name as 'localhost'. This will do a remote deployment on your local machine (thus not using the project's directory). You don't need to install the Remote Debugger tools, nor start msvsmon for this to work on localhost.
In case this helps anyone else, I had to do the steps outlined here to add the network share location to Windows intranet zone. In particular, I was having trouble with Visual Studio hanging on load when opening a solution on a network share (i.e. using VMware Fusion and opening a solution from my Mac's hard drive). I also had problems with PostSharp running in this scenario.
If i understand you correctly, your Visual Studio project files are stored on the network drive and you are running them from there. This is what I do and don't have any problems. You will need to make sure that you have set the security policy. You can use Caspol to do this, or via the control panel-admin tools menu.
"How can I get this to work?"
You have a couple choices:
Choice A:
1. Move all files back to your local hard drive
2. Implement some type of backup software on your machine
3. Test said backup solution
4. keep on coding
Choice B:
1. Get a copy of one of the FREE source control products and implement it.
2. Make sure it's being backed up
3. Test it
Choice C:
Use one of the many ONLINE source control repositories available. Google, SourceForge, CodePlex, something.
Well, my question would be why you are asking this. Is it not working when you are storing it on a network drive? I haven't tried this myself, and one problem I could envision would be that .NET code running from a network drive (ie. from the bin\Debug directory, also located on the network drive) would be running in a sandbox mode, unless you mess around with CASPOL (or use 3.5 SP1 which I hear has removed that obstacle).
If you have specific problems, ask about them. Never ask "Why is doing X not working?".
You're not saying if you're just one person or multiple persons accessing the same remote drive, but I'm assuming you're just one for each network directory. Is this correct? If not, no, there is no band-aid. Get version control, move the files back to a local disk.
I have wrote a program which tries to write a file in C:\windows\ directory. I have tested the program in several PCs with winXP, win7 (64 & 32 bit).But when i install it in my client's PC it crashed with the message : TODO ( file description ) has stopped working
Please if anybudy knows any solution then reply me.
The solution is not to write to the C:\Windows folder. You're not working for the Microsoft Windows team.
It is quite awesome that you gave your client a "TODO:..." product? Please edit the version info to reflect your product name~
As for crash scenario:
Check if your application really needs Admin rights, if yes, start with "run as admin" and see it it solves the problem.
View the problem details in either "Stopped working dialog box", or in Windows event viewer. In both, you can see the exception code (like 0xC0000005) and the DLL name. For this you should enable PDB file generation by enabling /DEBUG flag in linker setting (this is not same as _DEBUG macro in compiler settings!).
Put some file-logging or message-boxing (temporary) and see till where program goes properly. Yes, you need to make few changes, build and give again to your client (and please no "TODO" as product name - be professional!).
There are a few possible causes, among them no write access(perhaps the user running the program does not have write access to C:\Windows folder. Try to manually create a file in that location.) or faulty programming.
In any case, you have a few things to try to figure out the problem. If debug is impossible you should put the sensible parts of the code in try catch blocks (for example the part where you write the file). And if error is caught you can output a message about the part where the error is. You should also include a logging solution and add logs in various places of the code. After you install the updated application, when you get an error, look up in the log file to see where the code stopped.
Is it possible you have UAC turned off, but your client doesn't? Or, would the client's user not have administrative rights? A user process would not be allowed to write to the c:\Windows folder. If that's the case, trying to create a file would throw an exception.
The proper place to create a data file would be:
Application Data under the user's folder, if the file is per user.
ProgramData (Win7) or Application Data under All Users (XP), if the file is per application (log or so).
Apart from the issue of permissions the first thing that will cause your application to crash like that is the runtimes not being installed on your client's PC. Does your install package install the MSVC runtimes? If not, have you installed the MSVC redistributable runtimes on that PC?
"I have wrote a program which tries to write a file in C:\windows\ directory. "
That's your problem right there. Don't do that.
I'm developing a unit test project (let's say XXX.UnitTest) to test ViewModels in another project (XXX) in my solution. I can add the reference but when I build, an error states that it cannot find that same project (XXX)
Error 42 Could not load file or
assembly 'XXX, Version=1.0.2.66,
Culture=neutral, PublicKeyToken=null'
or one of its dependencies. The system
cannot find the file
specified. XXX.UnitTest
I did a clean rebuild of all projects in my solution.
I verified that the assembly with that version number (1.0.2.66) did exist in the path I was referencing.
I removed and re-added the reference both as a project and through the Browse tab.
I made sure that the version number was not specified in the csproj file.
I verified the referenced assembly with Dependency Walker.
I verified that both projects were targeting the x86 platform. (As suggested here Tips to help debug "Could not load file or assembly X or one of its dependencies")
Does anyone know what else can cause this problem?
Last week I had this same problem. It turns out my solution and projects were on a network resource. If I moved the solution to the local drive, the problem went away.
This problem happened regardless if I used a mapped drive or an UNC path.
This problem happened even with a Code Access Security Policy of "Full Trust" for the URL.
I believe the problem occurs on Windows XP computers and not Windows 7 computers, but have not tested or verified.
I believe it has something to do with the Share permissions.
If I try to use "offline folders" for the network resource, I get "access is denied".
-.
Setting NTFS permissions has no effect.
Adding user to administrators group has no effect.
I did not test to see if problem exists on removable local drives.
Work Around
Move solution and projects to a local hard drive.
Comment
I think this is a bug in Visual Studio 2010.
I came across this post while searching for the answer. Here is the solution. In the config file of QTAgent32.exe and devenv.exe in C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE, add the following element to the section:
<runtime>
<loadFromRemoteSources enabled="true" />
</runtime>
This can be added to machine config file (C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Config\ machine.config) for all VS2010 tools. Be sure to run notepad as administrator to allow machine.config to save.
See this link for details: http://msdn.microsoft.com/en-us/library/dd409252%28VS.100%29.aspx
I have the same problem. I'm running VS 2010 on Windows Server 2003; both running within a VM on a Mac. My VS project is in the mac home folder (~/) which is mapped as Z:\ from the Windows side. At build time, VS studio generates an error saying it can't find the UnitTests.dll or one of its dependencies. I get the same error with a small test project. If I move the project to the Windows C:\ drive, the dll reference resolves and unit tests work. I tried to add the reference Blanthor mentions, but couldn't get it to work.