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.
Related
If I open a single File with Visual Studio 2022 Community Edition, I run into the following problem:
Every header located in the Windows SDK Folders e.g. stdio.h can't be found.
Is there any way to tell VS where to look for these?
Couriously, if I open a Project Folder, everything works flawlessly.
This Problem also only occurs for certain Users, even though they all have the same rights.
Thank You in advance
Phil
I already tried reinstalling VS and The Windows SDK, nothing changed
I already checked the INCLUDE-Paths for the different Users, they are all the same
If I open a single File
Add folder of stdio.h to system environment path. Different Windows SDK versions own different direcories.
E.g. SDK 10.0.22000.0
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt
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
In my company, people used to work with Visual SourceSafe, but some years ago they decided to start working with GIT.
I started working here some months ago, and as such I've never set up a Visual SourceSafe environment.
While debugging dumps from older versions, this is giving problems: it seems that the dumps (taken using procdump) contain commands for retrieving source code, using Visual SourceSafe.
I've just installed Visual SourceSafe, and I was hoping that this would make it possible to get the older versions of the source code, but this is not the case. (For your information, even after having installed Visual SourceSafe, I don't see any SourceSafe information in Visual Studio's "Team Explorer - Connect" window)
(the original question contains quite some investigation information, which seems to be obsolete now that the answer of this question is known)
How things are related
[...] it seems that the dumps (taken using procdump) contain commands for retrieving source code, using Visual SourceSafe.
A crash dump does not contain commands. It contains version information about the EXE and the DLLs that were loaded. WinDbg and Visual Studio will then look for PDB files which match that version information. The PDB file then contains information about the source code.
To find PDBs, you need a symbol server and/or a local path with symbols.
SourceSafe
I've just installed Visual SourceSafe, and I was hoping that this would make it possible to get the older versions of the source code, but this is not the case.
Installing SourceSafe does not help. You'll need to connect to a repository using Visual SourceSafe Admin and grant yourself access rights.
Then, using Visual SourceSafe (not Admin), map a local folder ("Set working folder") and pull ("Get latest version"). You then have the source code locally and you can instruct your tools to use that path. For WinDbg, .srcpath and .lsrcpath should be correct.
You might need to get different versions by date if you really want to analyze with source code. To automate this process, you would need a source server, but you would know if you have one.
The age of the dumps
You say:
[...] some years ago they decided to start working with GIT.
So your source code should be in GIT, not in SourceSafe.
If your crash dump file is so old that it refers to SourceSafe, then consider it as obsolete and take a new dump. If nobody complains about crashes recently, I would no longer care (saying that as a former Test Manager).
Unbelievable: the issue is caused because the SourceSafe installation seems not to be complete:
In order to get it working, the following needs to be done:
Add the SourceSafe directory to the $PATH$ environment variable (C:\Program Files (x86)\Microsoft Visual SourceSafe)
Create the $SSDIR$ environment variable in order for SourceSafe to know where to look for the source code (should refer to the directory, containing the srcsafe.ini file).
We're working in quite a large project and is having a hard time getting people to configure their Visual Studio correct (tabs instead of spaces etc.). We found a great solution in using the EditorConfig extension for Visual Studio.
However there are still some developers that seems to ignore our request to install this extension to their Visual Studio and hence I'm wondering if there is any way to force an extension to be installed before a solution can be opened, maybe some setting in the .sln file?
No there is no such option built-in. If your machines are domain joined, you could push out the installer through System Center or domain logon scripts.
You could cheat and create a solution level pre-build step. Create a target file named: before.{solutionname.sln}.targets and store it next to your solution file. Check it into source control. In the targets file you can use standard MsBuild to see if the extension is installed (you'll need to check the file system probably) and if not present force the installation by calling vsixinstaller.exe to trigger the install.
I just installed Visual Studio 2015 Community on my computer. Until now I have been using Visual Studio 2010 Professional. Now when I try to run my MVC apps in the build in web server, I get the following error message.
The procedure entry point __CrtGetFileInformationByHandleEx could not be located in \WINDOWS\SYSTEM32\msvcp120_clr0400.dll
I get the same error message if I try to execute vbc.exe (the Visual Basic compiler) on directly at the command prompt. My MVC app also shows a YSOD with
Compilation Error - Compiler Error Message: The compiler failed with error code -1073741511.
How can I fix my VS so I can run my programs again?!
Steps I've tried
Uninstall VS 2015 Community
Uninstall and reinstall .NET 4.6 and .NET 4.5.2
DISM /Online /Cleanup-Image /RestoreHealth
The .NET Repair Tool
Run sfc /scannow
Manually rename the msvcr120_clr0400.dll file to msvcr120_clr0400.dll.corrupt and do 1-5
Uninstall and reinstall VS 2010 w/ SP1
sfc /scannow successfully replaced the msvcr120_clr0400.dll file, but it replaced it with the exact same CTP file as before!
EDIT:
The problem dll's from my system are available for download here:
32 bit
64 bit
32 bit msvcr
64 bit msvcr
Microsoft is aware of this issue with KB3098779 and 3097997:
https://support.microsoft.com/en-us/kb/3118750
The recommendation is to uninstall these patches and then rescan for updates. Newer versions of these security patches (that do not break the VB compiler) are now available.
Okay, I see it from the files you uploaded to the sharing service, your .NET install is corrupted. A standard DLL Hell problem, your c:\windows\syswow64\msvcr120_clr400.dll file is the wrong version. Something you can see when you use Explorer and navigate to the file. Right-click and select Properties, look at the Details tab.
Note the word "CTP" in the Product name, means "Community Technology Preview". A Microsoft term that means "beta version". Clearly you should not be having the VS2013 beta on your machine. Your msvcp120_clr0400.dll is correct, it is file version 12.0.52512.0. It depends on an exported function in the msvcr DLL that the CTP version did not yet have.
Exactly how this happened is always hard to reverse-engineer. You are the 3rd SO user that I know of that had this problem this week, a bit too much of a coincidence. Two basic scenarios, if you ever had the VS2013 CTP edition installed on the machine then the problem is that it didn't get updated like it should have. Otherwise a very typical problem with CTP editions, they are pretty dangerous because the uninstaller is always the last thing Microsoft gets right. And the problem was just never detected until you started using a program that required this export.
Or it was caused by a rogue installer, copying the old version onto your machine without checking the version number. Much less likely, installers never have a good reason to install this particular file since it is only ever used by the .NET Framework. My money is therefore on your machine getting corrupted by the CTP.
You need to solve this by getting your machine fixed. Not that easy, you can never be sure how many other bad DLLs are lying around from such a bad CTP uninstall. A shortcut is copying this particular DLL from a good machine. But best to get .NET 4.6 re-installed.
EDIT from OP:
This answer correctly identified the problem files but reinstalling (or any other common steps) didn't solve it. In the end I copied "good" files from another computer with the version number 12.0.20806.33440.
KB3098779 appears to be the culprit on our server. That is the patch that installed the rogue CTP msvcr120_clr0400.dll mentioned in the above answer.
Solution: we reversed out the patch set that applied KB3098779, and everything is working again.
FYI: this is a .NET framework 4+ issue, not Visual Studio. Our server is a standard 2012 IIS server: Visual Studio is not installed.
I had the same issue on Windows 8.1 although KB3098779 and 3097997 were not installed on my machine. Probably it happened after installation of ASP.Net 5.
The issue was that I had both mcvcr files in version 12.0.51670.34230 while mcvcp files were already in 12.00.52512.0. It was enough to copy both mcvcr files (from System32 and SysWOW64) in this version from my colleague's pc.
If you have problems with permissions set to TrustedInstaller on these file, you can run this powershell command and then change permissions as Administrator:
takeown /A /F C:\windows\syswow64\msvcr120_clr0400.dll
Microsoft have issued a notice on this.
https://support.microsoft.com/en-us/kb/3118750
As others have pointed out too many people in too short a time to be a coincidence. Not a VS issue, this is to do with a bad update from Microsoft.
The info from MS mentions two security patches (KB3098779 and KB3097997).
I have uninstalled only KB3098779 and my site is up was up and running. It required a machine restart to complete
KB3097997 uninstalled without a restart. I maybe didn't need to uninstall but seems sensible given it is also subject to the same notice from MS.