I migrated a solution from VS 2010 to VS 2017. When I build the solution, some files are reported to be missing while they're existing in the specified paths. The solution (which is in C#) was compiling in VS 2010 without any problem. The filenames are the same except their cases. I need to know whether file names are case-sensitive in VS 2017 while they were not in VS 2010? If so, how can I revert this feature, or set the option to ignore the file names cases?
This is not a VS issue. The drive has been mapped by SFTP Net Drive. For such virtual drives, in which the original drive is case-sensitive and will be mapped in Windows which is not case-sensitive, there's an option in the last tab, 'Drive', which one should set it. It's:
Handle case-sensitive filenames
Related
I'm using VS 2017 on Windows 10 Enterprise build 1803
I ran into trouble with a project that is deeply nested in subfolders and then I remembered reading something about Windows 10 removing the limit on MAX_PATH. I found this link Naming Files, Paths, and Namespaces which suggests that a large number of Win32 API calls can optionally not be limited to MAX_PATH.
I tried both toggling the value in the policy and changing the value in the registry. After a reboot Visual Studio still refuses to make a project in a path longer than MAX_PATH. When you browse to make the new solution it brings up a dialog
I'm looking at the list of API calls that are supposed to work with long paths and wondering just what the IDE or its tools are using that would preclude it from working? Did I not actually opt-in to long paths?
In Microsoft Visual Studio Professional 2022 (64-bit) - Current
Version 17.3.6 i still have issues with long paths. Restoring nuget packages and running tests does not succeed because of inaccessible files and folders.
As a workaround I used the subst command to associate the solutions directory temporarely to a driver letter. Thanks to IInspectable for the comment on the question about the subst command.
When I installed Visual Studio, it also placed hundreds of files on my external hard drive. And now the folder structure is full of "junk" that I don't want.
Is it safe to delete these files? Will deleting these files affect my Visual Studio installation (which is on a different disk) at all? Why does VS do this anyway? Why does it place all this crap on a drive I never even gave it permission to put it on in the first place?
You can safely delete any of those files, since, quoting Microsoft KB,
These temporary files are erroneously generated by the installer into the root directory of one of your drives, instead of the temp directory
Those are temporary files indeed and they, still quoting Microsoft,
are generated on the root directory of a drive that has the largest available space in the system
Check Microsoft knowledgebase pages like this for more detail.
What about archiving those files, opening visual studio and check it is still working?
If it doesn't just put the files back where they were...
You should be safe deleting those files. Someone already asked this question. :D
Visual Studio 9.0 Beta Program files in C:\
hope I was helpfull
Jasper.
Cause
These temporary files are erroneously generated by the installer into the root directory of one of your drives, instead of the temp directory.
Resolution
These files are unnecessary and can be safely deleted from the system. The functioning of the runtime library will not be affected by this.
Its a known bug and is fixed in VS2008 SP1.
Ref: https://support.microsoft.com/en-us/kb/950683
My TFS workspace is at C:\Users\...\MyProject, which I have mapped to X:\ using Windows subst command. In my Visual Studio 2010 solutions, this works fine for most of the projects. Only 2 of them are always linked (absolutely!) wo the C:\Users\... path, no matter what I do.
I tried:
Removing and re-adding them, obviously.
Removing the explicit absolute mapping for those 2 projects in my workspace settings. It is re-created as soon as I add the projects.
Manually twiddling in the solution file with Notepad. Makes the source control binding invalid, and 2.'s explicit bindings are re-created when I rebind them.
Some help would be very cool. I'm stuck for several hours only dealing with source control...
Cheers
Matthias
P.S. Some might wonder why I do the subststuff: As the project directory names are pretty long, the often exceed 260 characters, which makes many features in the VS/.NET environment stop working.
I have a (C++) project that I originally developed under Linux using make to build it. I would like to also have it run in Windows and am using Visual Studio 2005 to build it. The problem I'm running into is that Visual Studio places all objects into the same output directory. This doesn't work for me because I have source files with the same name in different sub-directories. This means that the last object (with the common name) overwrites all previous ones and thus I get link errors for the "missing" code.
Setting the output directory (even using the Visual Studio variables like $(InputDir)) at the project level doesn't work because Visual Studio passes all of the source files to cl.exe at once (i.e. $(InputDir) is evaluated once rather than for each input file). It appears that this problem can be solved by manually setting the output directory for each file (at a minimum, for the affected files), but this is less than optimal and error-prone.
Is there a better way to solve this problem? I would even appreciate it even if someone is able to suggest a way to get Visual Studio to compile files one-at-a-time so that setting the output directory at the project level would have the desired effect.
You might consider using different project for each directory or so. Otherwise, using the exactly same filename within a certain project might seem a bit strange. (Sort of a hierarchy within the project structure; something I've never seen before anyway.)
I'm trying to use Visual Studio 2005 with ClearCase eclipsed files (view private which "eclipse" a versioned file), but any time I save the file in VS, it becomes uneclipsed, and returns to the versioned file. In Linux, I use VIM instead of Visual Studio, and get around this problem by setting backupcopy=yes, thereby forcing it to save files by writing to a new file and then copying the new file over the existing one, instead of moving the original file out of the way (which undoes the eclipse) and then writing a new file, but in Windows, I'd like to use Visual Studio (since the tree also includes C# code compiled under VS). Is there any way to teach it to save files this way?
I do not think Visual Studio does save file in a particular way that may cause the file to be first removed, then written.
Considering that, with developer's environment as Windows with Visual Studio, eclipsed
files often happen just by writing a file case sensitive and later not case sensitive.
Hence, did you check the case of your file ?
Could you also check the config spec associated with your Windows view ? (and compare it to your Linux view).
I just spend 1/2h with a Visual Studio 2005 / ClearCase / dynamic view and... I do see the same thing!
The only workaround I can fathom is to add a non-selection rule:
element /my/private/file -none
That way, even though VS2005 remove then add the private file when saving it, ClearCase does not try to restore the versionned file, since it is not selected at all.
Si, the answer may not reside within VS2005 (I studied the options without seeing any obvious setting altering the saving process...), but rather within ClearCase.
Let me know if it helps.
As noted in the comment, the downside of this approach is "un-eclipse" can no longer be a matter of moving/removing the private file to let ClearCase dynamically restore the versionned file.
Now, that step must be complemented with another one, which is to comment the non-selection rule in the config spec.
If anyone is still reading this... I just discovered that Visual Studio 2008 appears to work just fine. Go figure...