I'm using two laptops and stored my C# code in OneDrive.
I am aware that sharing code via OneDrive is not be the best approach, but that's what I'm dealing with now.
I noticed that on laptop 1 I have to define the following path to the data file (mdf):
C:\Users\ Diet\OneDrive\Personal\VisualStudio2019\Repos\project\project\App_Data\data.mdf
On laptop 2, the path is different because the user I'm logged in with has a different name (or at least that's what I believe is the cause)
C:\Users\ Dieter\OneDrive\Personal\VisualStudio2019\Repos\project\project\App_Data\data.mdf
Updating this in the Web.config fixed the connection to the database, BUT building the solution still returns an error, also related to a cloud operation, hence why I think it is caused by the path in OneDrive...
The error message:
CSC : error CS0041: Unexpected error writing debug information -- 'The cloud operation was unsuccessful.
I welcome your insights. Thank you for helping me out.
I have my projects stored in OneDrive and had this same issue. The fix was to set the entire Project folder contents to "Always keep on this device".
Seems that building the solution in VS was attempting to write to files that were not cached locally from OneDrive. As soon as I changed the setting, the build worked!
I was also storing my project on OneDrive, got the same error after installing a new ssd.
Rebuilding the solution was enough for me.
Problem while receiving an update from Eclipse to svn. The error message is '0x00000: Open Project' operation completed with error: 0x000000: Unable connection to 'blah-' project. Please check that SVN meta-information exists and it is supporting the form ...
Except that the operating system has been updated from Windows 7 to Windows 10, nothing has changed, but it is annoying and cumbersome to see such errors every time we update. Of course, there are solutions such as cleaning up or re-connecting, but I want to prevent this problem from occurring fundamentally.
Can you tell me what to look at?
Thank you for reading it.
I'm getting the following error when attempting to install a nuget package into a standard .NET framework 4.7 project:
The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
I'm using Visual Studio 2017 15.3.3 Enterprise (latest and greatest).
Given that this is my package, I have full control over the source code. The interesting part is that I have used this package in the past with no changes in the name, but for this go round, I rebuilt it to add a feature and am now getting this error.
Even more interesting is that I have packages from the same library, with the same namespace conventions, with longer names, that work just fine and have installed into this same project with no problems at all.
I have already tried shrinking the package name, shrinking the class names within the package itself, cleaning out the build directory, cleaning out the package home from the nuget server (it's a local server with the latest nuget.server installed which otherwise works just fine), and even clearing out the bin directory of the project in question, clearing out ALL the bin directories of ALL the ancestors to the "offending" package, clearing out the package cache, rebooting the computer and rebuilding the entire nuget package chain from scratch, all to no avail. I was told by one of the MS MVP's that "they fixed that". Apparently not.
Any help would be appreciated here, I'm at my wit's end and have run out of ideas to try.
Thanks.
OK, big Thank You #danmosemsft who suggested digging around with the SysInternals process monitor. After fiddling with it for a bit, I finally figured out how to narrow the result set to just file activity. What I noticed, and the nuget engineers should TAKE NOTE of this: The problem was NOT a too-long project name, rather, nuget was attempting to update a package that was no longer there. Why it went away is a mystery yet to be solved. I normally stay out of the packages directory and do not fuss with the packages.config file. I think that this might have to do with my impatience waiting for VS to start, load all the goodies and then allow me to perform a "Manage NuGet packages" - update all. I remember seeing an update to either NUnit or FluentAssertions that wanted to perform some additional file activity aside from just installing the next version, a script I believe. Can't speak to it with assurance, I wasn't paying that much attention as third party updates usually "just work". I didn't see the "finished" line from NuGet so I think that was the root of my problem. Rather than wait until VS has settled down, I pushed it a bit (hey, the buttons responded so there shouldn't be any problems...).
As a result, the packages directory was absolutely chock full of old stuff that did NOT belong there. So, I manually cleaned up all the cruft, manually cleaned up the packages.config file, restarted VS, waited for it to settle down, performed my NuGet updates and viola! no problem - HAVING NOT CHANGED ANY OF THE ANCESTRAL PACKAGE NAMES BY EVEN A SINGLE CHARACTER.
So, what do I conclude from this? It is my belief, and the guys that actually build nuget and nuget.server should take a closer look at the errors being thrown, such that I think that the error is not so much a path too long error, rather it's a "hey, I didn't find the file I expected so the file name is full of junk (and probably too long now) so I'll throw an error that says it's too long and quit". It's seemingly a failure to handle a missing package/package directory that is causing this particular problem
I solved my problem by ensuring that all the package directories were clean of all junk and rebuilding from a clean source. My problem is now solved.
Thanks to all of you that responded.
Update: While the above contributed to the solution, it was NOT the answer. Here is the sequence of events that led to this problem and it's ultimate resolution.
The solution was created in the C:\User\Sam\Documents\Visual Studio 2017\Projects directory with the specified name of AWE.Lib.ADO.MsSqlSvr.ServerEntityHandler. This worked just fine, no errors. However due to a change in naming scheme from on high, the root directory for this project was changed from "C:\User\Sam\Documents\Visual Studio 2017\Projects" to "C:\User\Sam\Documents\Visual Studio 2017\Projects\DotNet_4.7\AWE 8.x". No problem, I thought - given that a co-worker who also happens to be a MS MVP had told me that all naming length restrictions had been removed in VS 2017. So...I moved the project from it's current home to the directory specified. Compiles just fine, brings in UPDATED BUT ALREADY INSTALLED nuget packages just fine, etc.
Or so I thought. When I needed to add a NEW (one that had not been a part of the solution before) nuget package to the mix, I received the above error. Turns out that the new name of the receiving solution is a few characters longer than VS will accept - the naming length restrictions are STILL IN PLACE.
How did I finally solve the problem: After struggling with this, I threw my hands up and decided to start all over again - a true File | New. So, I started with a new solution named as follows:
"C:\Users\Sam\Documents\Visual Studio 2017\Projects\DotNet_4.7\AWE 8.x\AWE.Lib.ADO.MsSqlSvr.HndlrServerEntity"
THIS GENERATES AN ERROR - name too long. I wondered at Nuget's error in that it specifies that the name should be less than 248 characters in length or 260 maximum.
What I am allowed to use iaw the new solution dialog is this: "C:\Users\Sam\Documents\Visual Studio 2017\Projects\DotNet_4.7\AWE 8.x\AWE.Lib.ADO.MsSqlSvr.HndlrServerEnt", for a total of 106 characters in length. If the directory is shortened, I can add to the length of the name. If I shorten the length of the actual solution name, again, VS'll accept it. So long as the total length of directory plus solution name is less than or equal to 106 characters, there isn't a problem.
The nasty bit comes from creating the solution in one location and having it work in all respects just fine, moving said solution to a different directory, still having it function in all respects (I did NOT need to add any new nuget packages yet), then trying to add a new nuget package to the mix after the move. THAT is what triggered the above nuget error.
So...the ultimate "fix", use a shorter name as it seems that 106 characters is the limit despite what the error messages are saying (and what the MS MVP was told/told me).
There is another reason for this error message by the compiler.
While building , make sure the source code is placed at a folder location which is less than 260 characters long.
For example, a path like C:\Users\User\source\Services\Exp\Sample-web-application-indot-net-displaying-RestAPI\Sample-web-application-indot-net-displaying-RestAPI\SportsStore is around 150 characters long but there are sub folders in the solution which in turn have source code files and so on.
Sometimes the overall length of the path of some files breaches the 260 character length.
I think the future versions of Visual Studio would have a bigger length allowance. Until then, we can make sure that our file names are not too long.
I was running into the same issue after I moved a project to another folder. In my case I closed VS renamed the .vs folder in root to 1.vs (effectively removing it) and re-opend my project.
In my case, I was first trying to install a package using Manage Nuget Packages for Solutions and was getting this error. Then I tried installing same package using Package Manager Console and it worked fine. I again uninstalled that package and tried installing using Manage Nuget Packages for Solutions and this time it worked fine as well.
Well in my experience all i had to do is move the entire project to my c: drive, delete unnecessary folders to ensure the path would be shorter. Done deal.
This error comes to me when I tried to copy the project folder to OneDrive and the problem is that OneDrive is not uploading long name files.
I've fixed this issue by just copying the project folder then paste it in the new laptop using USB.
I wish this could help
Move the folder of the project to a folder within a few levels from the root dir. For example the Desktop and voila.
Try to close Solution from File->Close Solution and opening it again.
For my case uninstalling, installing, or even updating NuGet packages, nothing was working but reopening(sometimes you can also close and open Visual Studio again) the Solution did the magic.
I have been using the TFS plugin for eclipse with my companies TFS server for several months. Last week, my laptop crashed while eclipse was open and a connection to the TFS was present. Now, every time I launch eclipse, I get an error stating a connection could not be made to the server, throwing a NullPointerException.
To try to fix this, I cleaned eclipse from my system and removed the installed plugin and then reinstalled eclipse and the TFS plugin. Now, I am no longer getting this connection error on launch. I added the original TFS to the list of servers in eclipse and it can see all of the projects (see http://i.imgur.com/SbgyuRx.png).
However, trying to use any of the projects leads to a screen with an error message saying Error querying workspaces: null. The error log shows the plugin in question as com.microsot.tfs.client.common, with the stack trace saying An exception stack trace is not available.
I am using the same exact plugin installation that I originally used. I have no idea why I'm getting these errors.
The error logs may be helpful. You can view them by going to Help > Team Explorer Everywhere Support, then clicking on the Logs tab.
Ultimately, though, this is probably some corrupt configuration files. TEE performs some various background tasks and I suspect one of those was interrupted in the middle of some file I/O when your computer crashed. Deleting the cache directory may be helpful:
~/.microsoft/Team Foundation
When you restart Eclipse, you should get a dialog box that indicates that your TFS server information cannot be located, but when you reconnect to that TFS server, your projects should return to being TFS managed.
I get this error :
Share project was failed.
svn: Error writing entries file for
'C:\workspace2\Test'
svn: Entry '' has inconsistent
repository root and url
But we get this error only on a particular PC. Also if we move the workspace in a network drive, everything works fine.
We are using FDT(eclipse based IDE).
We are totaly new to SVN...
I am looking for any advice who will helping us solving the problem
UPDATE:
Without any particular change the problem is gone ?!
Can you reproduced the issue with the latest Eclipse (Galileo 3.5.1)?
And what Subversion Eclipse plugin are you using? (Subversive or Subclipse?)
There was a bug with Subversive with path including a special character (like ~).
In your case, check the 'C:\workspace2\Test' has no special character in it, like a space at the very end. ('C:\workspace2\Test')