Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Sunday, August 28, 2011 3:32 PM
Could someone please tell my why Visual Studio 2010 cannot see drives mapped with the subst command. For example:
subst p: some\other\folder
When I try to create a new project on P: the file explorer in Visual Studio cannot see P:, nor can I force it to go there. This is incredibly surprising given that Windows Explorer has no problems navigating there. When I use Eclipse it also has no problems navigating there either. Does Visual Studio not know how to use basic file system APIs?
Does anyone have a workaround for this problem?
All my source control with Perforce is based on setting up a P: mapping.
- Eric
Eric Kolotyluk - software developer, music DJ, swing dancer
All replies (13)
Wednesday, August 31, 2011 10:01 PM ✅Answered | 2 votes
VS can see this. Just launch devenv from the command window where you've done the subst (elevated as pointed out earlier).
Subst doesn't seem to play too well with windows explorer. I guess it's per-process not a system-wide change.
Regards,
Matt Kaufman
Program Manager, Visual Studio Platform
blogs.msdn.com/b/visualstudio
Wednesday, August 31, 2011 8:09 AM | 1 vote
Hi Eric,
Welcome to the MSDN forum.
I have reproduced your problem. First, I mapped a drive(D:\ by subst command.
Then I can see it in Windows Explorer.
Next, I open Visual Studio 2010 IDE and open New Project dialog. Click “Browse…”.
From the picture, we can see “D:” and select this folder. Thus, I think Visual Studio 2010 can detect mapped drive automatically.
I recommend you try to start Visual Studio 2010 IDE under administrator and to see whether Visual Studio is able to determine mapped drive.
If you have any other concerns, please feel free to let me know.
Best Regards,
Alexander Sun [MSFT]
MSDN Community Support | Feedback to us
Get or Request Code Sample from Microsoft
Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Wednesday, August 31, 2011 3:16 PM
I always run Visual Studio under Administrator - it doesn't work properly if I don't.
Yes, in Windows Explorer I can see my drive P: as mapped by the subst command.
My Eclipse IDE can also see P: as well as all the files and directories there.
When I run Visual Studio it cannot see P: at all.
As far as I can tell, Visual Studio is the only application that cannot see P:
Actually, I just noticed that Visual Studio cannot see any mapped drives. For example my U: is mapped to a file server. It shows up in Windows Explorer, and my Eclipse IDE can see it as well.
This is clearly a Visual Studio bug in that it appears unable to see any mapped drives at all.
Is there anything else you can suggest? Is there some configuration setting somewhere that influences this.
Cheers, Eric
Eric Kolotyluk - software developer, music DJ, swing dancer
Wednesday, August 31, 2011 11:03 PM | 3 votes
OK, it was not clear from Alexander's comments that I needed to actually run subst in the elevated command window...
Now I see what the problem is. When you launch a cmd window in Admin mode, it cannot see the drive mappings from the previous shell. You have to actually run subst (again) in the elevated shell.
Once you do this you can just start VS from the desktop (not the cmd window), and then it can see the mapped drive. I am not sure what funkiness is going on that makes this work as I would not have expected it to.
From what I can tell any applications, such as Visual Studio, that have to run elevated cannot pick up the subst mapping from a previous non-elevated shell. Totally sucky user experience, but now I know what is going on.
subst seems to be playing fine with Windows Explorer, the problem is the context that subst is run in. As it is I run subst from a script in
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup
so now I have to run the script twice, once non-elevated and again elevated. I don't have any problems with Eclipse IDE (and other programs) because they do not need to run elevated.
There are several ways Microsoft could fix this "user experience bug"
- Fix Visual Studio so it does not have to be run elevated
- Fix Windows so when you launch an elevated shell it picks up the drive mappings from the previous shell. While this is the preferred solution, knowing Windows the way I do, it is not a possible solution.
- Fix Windows so that drive mappings are system global and not shell local. Somehow I also doubt this is possible.
Anyway, thanks for the help. I am unblocked now :-)
Cheers, Eric
Eric Kolotyluk - software developer, music DJ, swing dancer
Thursday, September 1, 2011 1:33 AM
Visual Studio 2010 runs fine under many circumstances without being elevated. To debug elevated processes or register COM servers, for example*, it does need to be elevated. There are many supports scenarios that do not require elevation. Personally, I rarely need to elevate Visual Studio 2010.
In what scenarios do you find you need to elevate Visual Studio 2010?
* There is a setting in the project properties for native projects that will virtualize the registration.
- Heath @ http://blogs.msdn.com/heaths; Visual Studio Professional Deployment
Thursday, September 1, 2011 3:13 AM
Before Visual Studio 2010 I was using Visual Studio 2005, and every time I run it I get a message "Administrator permissions are recommended for running Visual Studio 2005" so I just always ran it that way. I just tried running Visual Studio 2005 again and it still gives me that message.
When I installed Visual Studio 2010 I just assumed the same and so just always ran it with Admin privileges. I did not realize until just now that when you run Visual Studio 2010 it does not present you with that annoying and distressing message. Thanks for the tip :-)
I guess you can say that Visual Studio 2005 trained me to believe that Administrator permissions were required, if I did not want to suffer some unknown grief later on.
Even so, this whole experience with unpredictable and counter-intuitive drive mapping behavior is unnerving as I have wasted two days of development time trying to resolve the problem.
Cheers, Eric
Eric Kolotyluk - software developer, music DJ, swing dancer
Thursday, September 1, 2011 6:20 PM
Visual Studio 2005 was released before UAC was introduced into Windows. We released the Visual Studio 2005 Service Pack 1 Update for Vista to help address some of the issues. More information about that update is available at http://go.microsoft.com/fwlink/?LinkId=82676.
Visual Studio 2008 and newer are designed with UAC in mind, and to require as few privileges as needed (the goal of UAC to limit) unless they are needed. It then neatly asks you to prompt and restores your session. For example, if you had a solution loaded and want to debug an elevated process, it would prompt to elevate and reopen the solution in the elevated process.
- Heath @ http://blogs.msdn.com/heaths; Visual Studio Professional Deployment
Thursday, September 1, 2011 7:15 PM
LOL :-)
UAC bites me again! Way too funny.
Am I the only one who get reoccurring misery from UAC?
I think I have spent in excess of 200 hours fixing software that was broken by the introduction of UAC, and I have easily spent more than another 200 hours dealing with UAC administrative and software development misadventures.
I hope someone is benefiting from UAC, because we software developers are sure not.
Anyway, this is a hilarious end to this problem that started on Monday - another thing I can ultimately blame on UAC.
Thanks Heath for that insight on Visual Studio and UAC.
Cheers, Eric
Eric Kolotyluk - software developer, music DJ, swing dancer
Thursday, September 1, 2011 7:42 PM
Users are benefiting through more secure software. As I understand it, one reason was to reduce the number of apps that require elevated privileges when they actually don't need them. If least-privileged apps run even for administrators, the vulnerability is reduced. Many apps - and it would appear Visual Studio 2005 was no different - just request all available privileges for tokens rather than only what they need.
This blog post by the Windows 7 engineering team has more information: http://blogs.msdn.com/b/e7/archive/2008/10/08/user-account-control.aspx.
- Heath @ http://blogs.msdn.com/heaths; Visual Studio Professional Deployment
Thursday, September 1, 2011 11:44 PM | 2 votes
Good article Heath. Thanks for the reference.
It's funny how computer technology evolves...
Back in the 80's and 90's the bulk of malware was Unix based for two main reasons:
- Unix was the first network based operating system as most of the internet technology evolved there.
- Unix was initially extremely vulnerable because people were used to using in safe environments like university labs and such. This all disappeared with the emergence of the internet (see point one).
I worked on the project to develop Simon Fraser University's first campus-wide LAN, and also to join the three universities in the province together in a province wide LAN/WAN. I remember one day we discovered a very serious network virus - it was Macintosh based, primarily because Macintosh was the first personal computer system with sophisticated network capabilities - like file sharing. This virus spread incredibly quickly because there were over a thousand Macintoshes effectively connected to the same AppleTalk LAN - as it was a bridged network. We quickly learned the value of routers after that.
These days the vast majority of malware is Windows based because that is the most ubiquitous system on the internet. If you are a malware hacker why waste your time on small targets like Linux and OS X when you can really make a name for yourself with Window. Now that malware has become a profit industry this is even more true.
To be sure we are starting to see an increase in Macintosh malware because OS X market share has been rising, but for the most part the hackers still don't care about Linux too much, except for server attacks because of the myriad Linux servers powering the clouds of the internet.
Alas, poor Windows is still like a naked virgin in a dark meadow (please pardon the metaphor) - that bad people are mostly attracted to that. To be fare Windows 7 is more like naked virgin - with a black belt - in a dark meadow, but the bad people don't really see the black belt as a barrier, they see it more as a challenge, with the same prize at the end.
UAC is really a radical solution to the security issue. No other operating system does things in such a radical way, but maybe no other operating system has been so tempting to compromise/violate. The only point I am making is that we, software developers and users, are still paying a really high price for that kind of security.
Benjamin Franklin said: those who are willing to sacrifice freedom for security, with get neither, and deserve neither. Those old farts were pretty smart about some things.
:-)
Eric
Eric Kolotyluk - software developer, music DJ, swing dancer
Thursday, June 18, 2015 10:33 PM
"Benjamin Franklin said: those who are willing to sacrifice freedom for security, with get neither, and deserve neither. "
I was just reading this link and thought this might be of interest. According to the link, Franklin's quote has been taken out of context and molded to suit PR campaigns:
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
According to Wittes, the words appear in a letter widely presumed to be written by Franklin in 1755 on behalf of the Pennsylvania Assembly to the colonial governor. “The letter was a salvo in a power struggle between the governor and the assembly over funding for security on the frontier, one in which the assembly wished to tax the lands of the Penn family,” he explains.
The letter wasn’t about liberty but about taxes and the ability to “raise money for defense against French and Indian attacks. The governor kept vetoing the assembly’s efforts at the behest of the family, which had appointed him.”
Application Developer
Tuesday, November 24, 2015 3:06 PM
Try Map Network Drive as an alternative to Subst ?
Monday, January 4, 2016 1:34 PM
I had similar problem in 2013, explorer can see it but VS can't. I am assuming you are running the subs command as a batch file or directly from the command window. If batch run it as admit, or run cmd as admin before the subs command.
Hope that helps.