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.
I've tried this twice with the same result.
Error Message: OH-SCM-009 Error Occurred while sync. Could not find file 'O:\w11_10_0'
Version: OpsHub Integration Manager Framework-OVSMU-V1.0.1.006
Here are the changeset details
Close OpsHub Migration Utility.
Delete Folder w11_10_0 and Start Migration utility again.
Which will again create new folder and start syncing.
If you still getting this error, Can you please zip up and send us the log files from location :\Program Files\OpsHub Visual Studio Online Migration Utility\logs and email them to ovsmu#opshub.com Please include a reference to this request in your email so we will provide proper resolution to this
At one point if you moved code from one TFS Team Project to a New Team Project and DELETED the original team project then this may cause this issue.
I'm trying the new OpsHub TFS to Visual Studio Online migration tool and have run into a snag. After successfully setting up the migration configuration, I begin the migration.
On the first changeset of the migration, I receive the error:
"OH_SCM_009: Error occurred while sync. Access to the path 'O:\w15_2\ProjectName'"
Where ProjectName is the name of my project.
Through deletion and recreation of the project in VSOnline, I found that the folder 'w15_2' would change, an indication that this path (and subsequent access failure) is in VSOnline. I have confirmed the user I am using for migration is a project collection admin, project admin, and project collection service account (per the OpsHub help page).
I'm not really sure where to go from here... any ideas how to get around this access denied error?
The error indicates that the utility does not have ability to write at location at :\Program Files\OpsHub Visual Studio Online Migration Utility\TFS_Temp which is used by the utility for temp work space. (It is aliased to O drive). Please check to make sure that this location is writeable.
I have an ASP.NET MVC 4 application. I used NuGet to update all of the NuGet packages that were installed when I created the application. One of the packages was Microsoft.Bcl.Build.
After updating these, NuGet displayed the following message at the bottom of its window:
I have since restarted Visual Studio several times, but the message still exists. When I checked the installed packages, it did appear that the updated version (1.0.8) of the package was present.
How can I fix this?
Instead of deleting all of ~/packages, see if there are any *.deleteme files in ~/packages and delete them. Then restart Visual Studio.
I believe this problem is caused by the packages being read-only or otherwise inaccessible at the file system level.
Packages under source control
Temporary work-around (untested)
Check out the entire packages folder prior to telling NuGet to restart Visual Studio to delete the packages.
Permanent work-around
I found that this could be permanently resolved by removing the packages from source control and instead using NuGet Package Restore.
Packages not under source control
Temporary Work-Around
I worked around this by deleting from the solution's packages folder all of the files that referenced the package in question. Specifically, these were:
Folder: Microsoft.Bcl.Build.1.0.7
File: Microsoft.Bcl.Build.1.0.7.deleteme
In my case, the relevant package folders remained in ~\packages, although they were empty. I deleted the folders and restarted Visual Studio, and this warning went away.
I've just deleted the folders of each package that had error in the Packages folder in my solution folder and also deleted the .deleteme files and everything works fine!
1) Delete the entire ~\packagesfolder.
2) Restart VS.
3) Go to Manage NuGet Packages and Restore
I'll agree that this can happen when your packages folder is under source control. If you like to have it there, instead of removing the bindings you can check it all out, remove the package with the NuGet Package Manager, and then check in after wards.
In my experience, I found my answer on this thread, but using a combination of a couple of different answers above so I thought I would share what I found.
I had the exact same issue with "Microsoft.Bcl.Build" as the original poster. I had been trying to update references for other functionality using NuGet and had issues with some of the updates (compatibility then rollbacks). After this NuGet failure, I started getting this error.
I initially used the selected answer and Jedidja's answer and was able to get this to work, but it only partially solved my problem. It did fix the VS restart error, but it caused a downstream issue with TFS as I could no longer check in the project as it was expecting that "*.deleteme" file. This got me thinking, so I did some testing. When I restored the file from recycle bin, I started getting the restart error again.
Here is where I deviated from the posted answers and got my full resolution to my version of the problem.
When I checked into TFS this time, the project checked everything in (after I got the projects all updated using NuGet while the "*.deleteme" file was deleted). Once it checked everything in, I noticed that file was still pending check-in so I checked the solution in again and TFS accepted that file, but it was as a deletion....assuming it checked in the first time and then VS auto deleted it which required the second check-in. Anyway....after the last pending change check-in, the file was gone and VS no longer complained about needing to be restarted. I can't say for sure because the problem is gone, but I get the feeling if I had checked the code in before deleting the file in the first place it might have solved the problem without manual file manipulation.
** Hi, everybody.**
i resolve this problem this ways.
If you have source control run the vs as administrator ( it is important )
in the solution packages -> delete thing about packages.
sample -> i deleted all entity framework version folders.
restart the vs
open solution and solution right click -> manage nuget packages for this solution.
you will see restore button :) restore
that is all.
If you are using Entity Framework 6, then you can install the NuGet package "EntityFramework.SqlServerCompact".
This enabled me to use the standard ASP.NET Identity tooling that comes with the project templates for 2013 and MVC5.
I have a smallish utility library I made that I had created in TFS Beta 2 to test out TFS. I now have TFS rc1 installed(and Beta 2 uninstalled) and am trying to add my Solution to TFS.
I get an error saying that it is already bound to my old TFS, which was on a different system then this one. Strangely, when I go into Source Control and look at the bindings it says there aren't any. Also, I manually deleted the .vss and .vsc files and it still does it.
Ideas? I looked through the numerous other SO topics related to this but unless I missed one none of them are dealing with my issue.
Ideas?
Grab the TFS Sidekicks from Attrice. They have a workspace sidekick, you can pretty quickly find your old machine and unbind/delete that workspace from TFS.
Once you install:
VS Menu Bar
Tools
Team Foundation Sidekicks
Workspace Sidekick
Owner will defult to you, just clear machine name
Search
Select old workspace, click the red X to delete
I had old server entries too and I fixed it by using the workspace sidekick mentioned here and then using the command line to get the rest that the tool couldn't find.