We just did a move from storing all files locally to a network drive. Problem is that is where my VS projects are also stored now. (No versioning system yet, working on that.) I know I heard of problems with doing this in the past, but never heard of a work-around. Is there a work around?
So my VS is installed locally. The files are on a network drive. How can I get this to work?
EDIT: I know what SHOULD be done, but is there a band-aid I can put on right now to fix this and maintain the network drive?
EDIT 2: I am sure I am not understanding something, but Bob King has the right idea. I'll work with the lead web developer when he gets back into the office to figure out a temporary solution until we get some sort of version control setup. Thanks for the ideas.
While we do use Source Control, we do also run all our projects from Network Drives (not shared directories, private directories on network drives). The network drives are backed up nightly, and also use Volume Shadow Copy, so if you need to revert to something before it made it's way to SC, then you can.
To get projects to run correctly with the right permission, follow these steps.
Basically, you've just got to map the shared directory to a drive, and then grant permission, based on that Url, to all code. Say you map to "N:\", then use "N:\*" as your Url pattern. It isn't obvious you need to wildcard, but you do.
The question is rather generic so I'll give an answer to one issue I was facing.
I run Visual Studio 2010 using a Parallels virtual machine on my Mac while keeping all my projects on the mac side via a network share. Visual Studio however wouldn't load the projects assembly files from there. Trying to set the rights using "caspol" alone didn't help in my case.
What finally worked for me to allow Visual Studio to load assemblies from a network share was to edit the file
"C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe.config" (assuming a default installation).
in the xml "<runtime>" section you have to add
<loadFromRemoteSources enabled="true"/>
You may have to change the permissions on that file to allow write access. Save the file. Restart Visual Studio.
In the interests of actually answering the question, I copied this comment from jcarle.com:
Trusting Network Shares with Visual Studio 2010 / .NET Framework v4.0
January 20, 2011, 4:10 pm
If you are like me and you store all your code on a server, you will have likely learned about trusting a network share using CasPol.exe. However, when moving from Visual Studio 2008 (.NET Framework 2.0/3.0/3.5) over to Visual Studio 2010 (.NET Framework 4.0), you may find yourself scratching your head.
If you are used to using the Visual Studio Command Prompt to quickly get to CasPol, you may find that some of your projects will not seem to respect your new FullTrust settings. The reason is that, unless you are carefully paying attention, the Visual Studio Command Prompt defaults to adding the .NET Framework 4.0 folder to its path. If your project is still running under .NET Framework 2.0/3.0/3.5, it will require setting CasPol for those versions as well. Just a note, I have also personally had more success with using 1 as a code group instead of 1.2.
To trust a network share for all versions of the .NET Framework, simply call CasPol for each version using the full path as below:
C:\Windows\Microsoft.NET\Framework\v2.0.50727\CasPol -m -ag 1 -url file://YourSharePath* FullTrust
C:\Windows\Microsoft.NET\Framework\v4.0.30319\CasPol -m -ag 1 -url file://YourSharePath* FullTrust
I would not recommend doing that if you have (or even if you don't have) multiple people who are working on the projects. You're just asking for trouble.
If you're the only one working on it, on the other hand, you'll avoid much of the trouble. Performance is going to out the window, though. As far as how to get it to work, you just open the solution file from VS. You'll likely run into security issues, but can correct that using CASPOL. As I said, though, performance is going to be terrible. Again, not recommended at all.
Do yourself and your team a favor and install SVN or some other form of source control and put the code in there ASAP.
EDIT: I'll partially retract my comments. Bob King explains below the reason they run VS projects from a network drive and it makes sense. I would say unless you're doing it for a specific reason like Bob, stay away from it. Otherwise, get your ducks in a row before setting up such a development environment.
So I was having a similar issue. Visual Studio wouldn't recognize a network location I had mapped for a drive letter for anything. The funny thing is, it worked for a day. I set up my project and began working on it and had no issues. Then, I shut down and the next day nothing works. I couldn't read/write files in code, output my executables or anything. My project is local but my output was intended to be thrown up on the network.
Anyways, the problem is probably about the administrator context but one way to fix it which I found while digging around online is to get Visual Studio to browse to the drive in question some how. There are plenty of ways to do this but VS will magically be able to recognize mapped drive letters. My solution is to go the the Debug Output Location in the Project Properties, click browse and go to my previously made output location on my network drive and Voila!!!
I wanted to put this up because I spent half a day trying to figure this out and figured it might save someone else some time. Thanks much and good luck!!!
Erik
I understand this is an older thread, but this was the best thread I found when looking to solve a similar issue I had visual studio 2013 on a virtual box (using Win 8.1) and the code on the host machine (Win 7). Although I could open the solution, I could not compile. All of the other answers on this relate to older software, so I am adding this answer to update this frequently found question with the solution that worked for me.
Here's what I did; Made a registry entry to be able to use a UNC path as the current directory.
WARNING: Using Registry Editor incorrectly can cause serious, system-wide problems that may require you to reinstall Windows NT to correct them. Microsoft cannot guarantee that any problems resulting from the use of Registry Editor can be solved. Use this tool at your own risk.
Under the registry path:
HKEY_CURRENT_USER
\Software
\Microsoft
\Command Processor
add the value DisableUNCCheck REG_DWORD and set the value to 0 x 1 (Hex).
WARNING: If you enable this feature and start a Console that has a current directory of an UNC name, start applications from that Console, and then close the Console, it could cause problems in the applications started from that Console.
Found this information at link: http://support.microsoft.com/kb/156276
How about we rephrase this into a question that everyone can answer? I have the exact same problem as the initial poster.
I have a copy of VB 2008 (recently upgraded from VB6). If I store my solutions on the backed up network drive, then it won't run a single thing ever. It gives "partially trusted caller" errors for accessing a module, even when "allowpartiallytrustedcallers" is set in the assembly. If I store the files on my (not backed up) C:, then it will run wonderfully, until I put it on the share drive for everyone to use, and I'm back to my same problem.
This isn't a big request. I just want to be able to put a solution and executable on the share drive and run it without an absurd amount of nonsense about security. I shouldn't have to cram all my work into form files.
-Edit: I found the problem with why it was ignoring the AllowPartialllyTrustedCallers command. I'm trying to reference ADODB, which doesn't allow partially trusted. So, no network executable can access a database? What does Microsoft have against intranets anyway?
I was facing the same issue just recently so this answer is more for the sake of keeping track of my own knowledge. Anyway, should soumeone find it useful, below is the issue and the solution.
Issue:
NET 4.0 projects, SVN repo, checkout folders are on local drives, referenced assemblies are build by build server and available on a network drive. Visual studio on W7 is is able to add the reference but unable to build projects.
Solution:
Since NET 4.0 does not automatically provide a sandbox anymore for network assemblies, you have to make those full-trusted via machine.config update. http://msdn.microsoft.com/en-us/library/dd409252.aspx
I had a similar problem with opening Visual Studio projects on a network drive, and I fixed it by creating a symbolic link on my local C:\ drive that points to the UNC directory
e.g.
mklink /D "C:\Users\Self\Documents" "\\domain.net\users\self\My Documents"
then you can just open the project using the C:\Users\Self\Documents\ path, instead of the UNC path
(You have to be careful, because Visual Studio will automatically redirect you to the '\\domain.net..' path if you double click the symlink when you're browsing for the project. I had to copy paste the 'C:\Users\' path to get it to open with the drive letter path)
Don't do it. If you have source control (versioning), you do not want your files on a network drive. It totally bypasses all you want to achieve by using source control, because once your files are on a network drive, anyone can modify them .... even while you're currently building your project. Ka-boooom!
PS: this sounds like a typical case of over-engineering to me.
Are you having any specific problems?
If you allow more than one person to open the solution, your first problem will be that the .NCB file (Intellisense) will be locked exclusively and only one user will be able to browse the class tree. And of course you have the potential for one user's changes to overwrite the other user's changes.
You should be warned that some feature in Visual Studio will refuse to work with network drive.
For example, mdf file of SQL Express user instance must be located in local drive.
For another example, if you use UNC path, you have to make sure they are short enought.
i found this helpful while trying use vc11 with parallels which run on mac:
http://social.msdn.microsoft.com/Forums/en-US/toolsforwinapps/thread/2ffdcb01-c511-4961-834b-afd5f2fbb8e1, and specifically:
1) You can switch from local debugging to remote debugging and set the machine name as 'localhost'. This will do a remote deployment on your local machine (thus not using the project's directory). You don't need to install the Remote Debugger tools, nor start msvsmon for this to work on localhost.
In case this helps anyone else, I had to do the steps outlined here to add the network share location to Windows intranet zone. In particular, I was having trouble with Visual Studio hanging on load when opening a solution on a network share (i.e. using VMware Fusion and opening a solution from my Mac's hard drive). I also had problems with PostSharp running in this scenario.
If i understand you correctly, your Visual Studio project files are stored on the network drive and you are running them from there. This is what I do and don't have any problems. You will need to make sure that you have set the security policy. You can use Caspol to do this, or via the control panel-admin tools menu.
"How can I get this to work?"
You have a couple choices:
Choice A:
1. Move all files back to your local hard drive
2. Implement some type of backup software on your machine
3. Test said backup solution
4. keep on coding
Choice B:
1. Get a copy of one of the FREE source control products and implement it.
2. Make sure it's being backed up
3. Test it
Choice C:
Use one of the many ONLINE source control repositories available. Google, SourceForge, CodePlex, something.
Well, my question would be why you are asking this. Is it not working when you are storing it on a network drive? I haven't tried this myself, and one problem I could envision would be that .NET code running from a network drive (ie. from the bin\Debug directory, also located on the network drive) would be running in a sandbox mode, unless you mess around with CASPOL (or use 3.5 SP1 which I hear has removed that obstacle).
If you have specific problems, ask about them. Never ask "Why is doing X not working?".
You're not saying if you're just one person or multiple persons accessing the same remote drive, but I'm assuming you're just one for each network directory. Is this correct? If not, no, there is no band-aid. Get version control, move the files back to a local disk.
Related
I have a software written in C++ installed in some 1000 PC which is having some difficulties with windows UAC. I'm trying to make things work properly but I would need some help to understand the problem and find correct solution.
Situation is as follows: I need to write some data in some text / xml files, so I started (in XP) to write them in the executable folder. Not recommended, I know. When Vista kicked in, all files started being saved to the VirtualStore folder, which was fine for me, so I left things untouched. I had some issues back then with a couple of users (see problem 1) but I fixed them by hand and that was it. Now with Windows 8 I'm facing different problems (problem 2) and I want to fix them properly once and for all.
First problem: with Windows Vista it happened that some users eventually found their software "empty", as it was when just installed. All their work on it was gone. It turned out that suddendly Vista was looking for their files in C:\Program Files\{MyApp} instead of looking in the VirtualStore. Copying the files from VirtualStore to Program folders solved the problem, never understood why
Second problem: now with Windows 8 some users [a minority of them] experience a different, strange fact; my app does not seem to be able to create files in the VirtualStore, but it can edit existing files. So if I create the files manually, everything works. If not the app does not work: files are not modified neither in the program folder nor in the virtual store
Now I want to fix up things. My plan is to move all the files that need modifications in CSIDL_LOCAL_APPDATA and to have the software save stuff there. Only executables will be in the program folder. For backward compatibility, though, it seems I cannot use SHGetKnownFolderPath which seem to be Vista+ specific. So I would use SHGetFolderPath, which is deprecated, I know, but should work in XP and act as a wrapper of SHGetKnownFolderPath in Vista+, which is good for me.
My questions:
any ideas about my problems 1 & 2? I'd like to understand them in order to be sure I defeated them complitely.
is my plan UAC compliant? As far as I understand it is, but...
any way to assure XP compatibility but for my workaround? I do not feel comfortable using deprecated functions, but I definitely do not want to have two versions (XP and Vista+) to deal with!
Thank you very much for any help you can provide.
Luca
These are my ideas to problems 1 & 2:
1. If you are writing the files your application is working with, your files will be written in a sub-directory of C:\Program Files. In order to write files at this location (C:\Program Files), your application must be run as Administrator. For compatibility reasons Windows Vista will write data to VirtualStore, if you try to write data to directories where you need Administrator rights to write data to.
2. Windows 8 does not use VirtualStore anymore. Read access does not require Administrator rights, however.
Yes, your plan is UAC compliant. Your program and the files your program uses must be saved in two different directories.
I would use the ShGetFolderPath function in order to get the path of the AppData directory. Additionally this function is compatible with Windows XP. You might check the operating system version and use the appropriate function/interface for this version. GetVersion and GetVersionEx have been changed in Windows 8. This is why I recommend the use of the Version Helper functions for version checking purposes on Windows 8.
This ought to be simple, but seems to be anything but.
I wish to create an installer that can be used by those using group policies to install products. I do not know then if this must be an MSI, or an EXE. Can an EXE install be installed via a group policy? I chatted with another Wix novice who seemed to think it was a bad idea to have an install that was a plain MSI file.
My product uses the Visual C++ 2010 redistributables. I do not wish to use merge modules. Both this and this link give some of the disadvantages of using them. I object to 1) installing things that the user has not consented to, and 2) not having a control panel uninstall item with a version number that users can inspect and see if they have the latest version of. Thus, I am not interested in responses consisting of people lecturing me on why I ought to use merge modules. If what I am asking for is truly IMPOSSIBLE without merge modules, then please explain why.
I do not know if it is necessary to use a bootstrapper to kick off an EXE install. I gather that it is, but it seems bizarre for me, for an MSI with such involved tables and descriptions, not to be able to kick of a mere EXE, ON THE CONDITION that the redistributable is not installed already.
If it is necessary to use a bootstrapper, I would like to know if anyone can find a complete example, with both bootstrapper and Wix code, for an example of a product install; ideally, together with the command lines necessary to compile them, for such a common case as installing a VC++ 2010 (or possibly 2012) program, together with its redistributable - with the latter being installed as the EXE.
I have found this to be straight-forward and easy to do in Inno Setup Pascal - except for the Group Policy part. I have found anything but COMPLETE examples and/or straightforward explanations to accomplish this using a Microsoft installer. No matter what Microsoft says, I would consider such an installer to be best practices. My code is not managed, and I would like to support XP. Thus, a bootstrapper that requires some .net to already be installed would only add another unsolved layer of complexity to the problem. One that statically links to a .net library might not be too bad, if it did not create very much overhead. My MSI install seems to work pretty well. I did not realize that installing a vcredist_x86.exe would be a problem with such an elusive solution. I do not have Visual Studio. I am using the Qt framework, and have Visual Studio installed only to compile my application. If you have a bootstrapper solution, please specify which bootstrapper you are using. Ideally, the same idea could be extended to more than one prerequisite, and the same coding pattern could be used. If there were a way to use a merge module or additional MSI so that the redistributable would have its own control panel entry, that could be acceptable.
Brownie points for suggesting a mailing list, forum or well-populated chat channel to talk about Wix that does not require one to receive a lot of unnecessary mailing list traffic.
Group Policies by default don't allow EXEs to be installed. I did read about some admins that repackage EXEs into MSIs to deploy them via GPO but that is rather hacky. There is also the possibility to script the deployment - GPOs support script execution, machine or user level.
You can't embed an MSI within another MSI either because only one installation can execute at any time (Windows Installer design).
I don't know how you will be providing your product to your customers but vcredist_x86.exe (I am trying this with the v100 version) uncompresses into the root folder and generates an msi and a cab (vc_red.msi and vc_red.cab) among other files. If you provide these to your customers they can add them to the same GPO used to deploy your product.
I am running windows 7 and I am trying to get this IDE to work and I am have an incredibly frustrating time making it work.
I am following these instructions
Quick guide:
File > New > Project
Select "Win32 Console Application"
Enter a name and location, select OK
In the Win32 Application Wizard under "Application Settings", select "Console Application" and select "Empty project".
Click Finish.
On the right (or left) hand pane should be Solution Explorer. Open it and right click on the "Source Files" folder and Add > Add New Item.
Select C++ file (.cpp)
Write code, hit F5 to start with debugging, ctrl+f5 to start without debugging.
After step 4 I get the error, "The platform root directory "E:..........\MSBuild\Microsoft.cpp\v4.0\Platforms" does not exist.
What do I do? I installed it in my E drive, maybe what it wants is on my C drive? It is not possible for me to install it there though because I am using a SSD for my C drive.
Update, I have tried to uninstall and reinstall and then clear my temp folder and then reinstall and then uninstall with the uninstall utility and then reboot and the reinstall and none of that works.
I turning off my firewall and antivirus and installing and running and that did not help at all. Next I am going to format my hard drives and try and install again.
I tried installing the ultimate version and I had the same problem. I have no idea what to do, it seems like I am out of options.
Any ideas?
My best guess now is that I have to manually install the missing files somehow, where can I find those?
I installed Dev C++ and it works fine, should I just continue using this (as far as I can tell superior program) or try and fix Express?
Microsoft Visual C++ 2010 Express
The platforms root directory "E:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms" does not exist.
OK
--------------------------- The microsoft.cpp part is missing but it exists in the C drive. I copied that over to the E drive and now when I open a project I get a blank screen, if I open older ones it says I need .net framework 4.0 which I do have.
This has to be the worst program I have ever had to deal with, I have played video games in beta that worked better than that.
I think I got this working, I am not sure though.
It appears to be working but I get some strange errors, I am just going to accept this because at least now after an entire weekend I can begin my homework.
Since - as you've pointed out - you've already reinstalled VC++ and nothing seems to work and you've tried everything - you may also try this (if you've not given up yet):
you may try trial version of full visual studio VS2010 trial
you may try to install your VS express on friends PC on 'non-C' drive
perform antivirus check of your system
after installing full version - install service pack (VS SP)
ensure you uninstall all (if any) prior versions of VC, VB, VC# or visual studion that you may have
always reboot after installation
If (1) works this may suggest your VS express is somehow corrupted (would be weird to be able install it than - but I've seen so many weird things that I may believe it ;-)
If (2) works this may suggest your PC/OS is causing problems.
Let me/us know if any of above helps.
I would uninstall and reinstall the whole thing rather than keep spinning your wheels. Honest!
Q: Your "E:" drive is a read-write drive, isn't it?
Q: E: is the drive you installed to, correct?
Q: Hopefully, E: is a normal disk drive, isn't it?
If not (if it's a shared network drive, or a nice'n'slow USB drive), please consider installing VS2010 to a hard drive.
MSVS should not be hard to install or use. It takes awhile ... but it's usually pretty straightforward.
If you've having problems, then I strongly urge you to 1) uninstall, 2) reboot, 3) reinstall.
IMHO...
http://social.msdn.microsoft.com/Forums/vstudio/en-US/69925677-8a07-46a4-8b0e-c9ddef17a7af/visual-studio-2010-fails-in-c-trying-to-set-the-references-parameter?forum=vssetup
The solution in a similar case of installing VS2010 C# on a seperate drive was to copy the Reference Assemblies folder from C:\Program Files to E:\Program Files.
When I had the the same error as the poster above on VS2010 C++, when installing to a different drive, I did the same for the MSBuild Directory and the errors in VS2010 C++ disappeared.
It seems that Visual Studio installs/creates those directories on the same drive as windows 100% of the time, but the registry values still look for them on the same drive that you installed Visual Studio on.
I have searched and found no answer to this
I have a weird problem when running executables through developer studio (2008): a basic 'hello world' exe works OK when created through the usual dev studio project creation mechanism, but when trying to run a library based program the software crashes with STATUS_BAD_NETWORK_PATH. The program uses Qt and zlib behind the scenes and is written in C++, but (as far as I'm aware) is not dependent on any particular network locations on initialisation; we do have Sophos installed on the PC too.
The weird thing is that one cant even step into the main: the program fails well before this with the error. If we plug the network in, it starts up just fine ... The odd thing is this only occurs on a specific 64 bit Windows 7 machine.
Does anyone have any tips as to how to trace where the issue is? We've tried tracking using procmon but it is not very revealing; no obvious failures up to the point where the program crashes.
We have now figured out the answer. It transpired that there were 2 issues:
Firstly a wrapper .bat script that was launching developer studio was setting the PATH environment variable: a location in this path was being specified using a UNX style path (e.g. \\a\location\somewhere) rather than a mapped drive. The executables were not actually using this location but when the network was unplugged this it seems that this was disrupting things from dev studio
This, in tandem with a network configuration error on the PC, meant that deep down in the runes, something was failing.
So - advice if you see such an error
Check your PATH and make sure it is sensible
Look in your PC's configuration logs, and see if you can see any networking issues
...
I have an old, old VC++ app that we've ported to VS2005. Our existing users need to get the VC++2005 DLLs, so my app is placing the vcredist_x86.exe on their machines and running it. I check a registry entry under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide\Installations\ which is x86_Microsoft.VC80.MFC blah blah 8.0.50727.762 blah blah...
But... it appears that this doesn't exist on Vista. What is the correct entry to check to make sure that the vcredist ran to completion, so that I don't have to run it again?
Thanks!
I never found anything definite on this, although you could look in the winsxs folder in the users windir for the right folders and files.
I've got our app's installer running it quietly when they install, which won't cause any problems if it is already there.
so my app is placing the
vcredist_x86.exe on their machines and
running it.
This is a highly irregular way of doing this.
Usually the side by side packages are automatically added to the dependencies of an installer object under the "detected dependencies"
Keeping it simple: just run the redist setup as part of a batch file that writes some registry value when it's done (so you could check and not run it twice) or write some file to a known location.
true, this way if your uses ran vcredist on their own sometime in the past your first installation would be superfluous, but I guess it can't really hurt and isn't that big of a deal.
Other than that (I realize it ain't pretty) I suspect you'll have to check that every single file that comes in the 2005 redist package is there (wasn't deleted by any chance or damaged), which is pretty much what the redist setup ought to do anyway.