I am creating a visual studio setup project using vs2010. I want my application to be installed in c:\manufacturer\ProductName. I used [HOMEDRIVE] as the defaultLocation of "ApplicationFolder" which will points to c:\ at the installation time. However, when i put [HOMEDRIVE][Manufacturer]\[ProductName] as the defaultLocation, it raises an error at the installation time saying "Could not access network location Manufacturer\ProductName". I appreciate any kind of help or suggestion.
You can use this default path:
[WindowsVolume][Manufacturer][ProductName]
WindowsVolume property is automatically resolved to the Windows partition (usually C:). Also, all predefined folder property values are ended with a backslash (). So you don't need to add one after WindowsVolume.
Related
I am hit with a mysterious win32exception here when i was attempting to do a mysqldump(backup) to backup my database on a windows form , .Net Framework 4.0, Visual Studio 2010 on a x64 Windows 8.0 machine.
All went fine except for this process where it crashes mysteriously where they said that the system cannot find the file specified.
Any direction on how I can solve this? Thanks!
You are using UseShellExecute=false. In this context, the MSDN specifies that the FileName property should be a fully qualified path to the executable. So, just writing mysqldump.exe as the filename is not enough to start the process.
I recommend to set also the WorkingDirectory to the path where the mysql binaries are installed because, if the process launched needs some local installed resources, withoud a WorkingDirectory set you could have hard times to understand errors about files not found or missing configuration files.
I have been trying to publish my service to windows azure. The service consists of a single webRole, however I have added remote login functionality published it and built it a few times, and now all the sudden it will not build. The reason it gives is that
Details below:
"Error 56 The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters. C:\Program Files (x86)\MSBuild\Microsoft\Cloud Service\1.0\Visual Studio 10.0\Microsoft.CloudService.targets 202 5 FileSystemCreator"
I have gone on all the forums, I have used CSPack command line for packaging the service which is fine but I'm having a really hard time configuring the certificate for remote desktop connect and I would like to take advantage of this feature as I am creating some websites in the onStart event and I would like to peek into IIS. Some microsoft employees do agree that this is a bug and the have promised a fix this issue, refer to post . I am using VS2010 and I do not know how to fix this bug.
Can anyone please help, or point me to a place where I can get any help.
I ran into the same problem with a new solution.
Note that, unlike Eugenio Pace's response suggests, the error occurs only when deploying to Azure (and not when running the project in the Azure Compute Emulator).
Try adding the following line to the first property group of your Windows Azure Visual Studio Project file (*.ccproj):
<ServiceOutputDirectory>C:\Azure\</ServiceOutputDirectory>
The trailing slash (for whatever path you select) appears to be required. This folder will be deleted each time you create a package if it exists.
This setting seems to redirect the working folder for the package to a shorter base path, preventing the path too long error.
Credit goes to: http://govada.blogspot.com/2011/12/windows-azure-package-build-error.html
Perhaps the local folder used to store temporary development fabric is too long. See Windows Azure - Resolving "The Path is too long after being fully qualified" Error Message.
I was having this problem as well when deploying a Node.js project to Azure.
To fix it, I had to change my "TEMP" and "TMP" user environment variables to something shorter than their default values.
In my case, they were pointing by default to %USERPROFILE%\AppData\Local\Temp, changing them to C:\Temp solved it.
Make sure you restart Windows after.
The better solution may be to create a symbolic link to your project folder. This doesn't require moving files or changing system variables. Open up the command prompt as an administrator and run this:
mklink /D C:\Dev C:\Users\danzo\Source\Workspaces
Obviously you can change "C:\Dev" to whatever you want it to be and you'll need to change the longer path above to the root directory of your soltions/projects folder.
Same problem happened to me when I try Packaging an Umbraco project for Azure (https://github.com/WindowsAzure-Accelerators/wa-accelerator-umbraco/wiki/Deployment), I found the solution is to: Copy and rename the long-name path and folder to "C:\someshortname".
(solution was suggested by this: link)
I tried all the above 2 approaches:
-change TEMP and TMP enviromental variables
-<ServiceOutputDirectory> path
and didn't work.
In my case, I had to move the whole project to a shorter path C:\ and worked.
I'm using W7 and VS12.
When you run a cloud service on the development fabric, the development fabric uses a temporary folder to store a number of files including local storage locations, cached binaries, configuration, diagnostics information and cached compiled web site content.
By default this location is: C:\Users\\AppData\Local\dftmp
Credit goes to Jim Nakashima of Microsoft :
https://blogs.msdn.microsoft.com/jnak/2010/01/14/windows-azure-resolving-the-path-is-too-long-after-being-fully-qualified-error-message/
In order to change the temporary folder, a user environment variable has to be created :
It is named _CSRUN_STATE_DIRECTORY
Give it a value of short named directory like :
c:\AzureTemp
Don't forget to restart Visual Studio in order to have the environmennt variables to be read again
It fixed many compilations problem !
I have a very simple application installer that needs to add an action to the shell menu of all files (HKCR*\shell), and I've run into a brick wall: how do I insert the installed path of the application into a registry value? I've tried everything I can think of:
[Path]
[ApplicationFolder]
[ApplicationPath]
[InstallPath]
[InstallRoot]
[InstallFolder]
[InstallTarget]
[TargetPath]
I even tried adding one that I know works in other places ([Manufacturer]) to make sure that the bracket-values syntax actually works in the Registry (it does).
Anyone know, or at the least, have any ideas that I haven't tried?
The one you are looking for is [TARGETDIR]
My problem is this: I am getting a TFS build failure that I have tracked back to what appears to be a missing Registry key under SOFTWARE\Microsoft\VisualStudio\9.0Exp.
This machine had the VS SDK 1.1 installed via a command line: msiexec vsski.msi
So, I am guessing that I need to pass some properties to the msiexec to tell it that it should install some component which isn’t getting installed by default – is this correct? If so, can anyone point me to the correct property?
msiexec vssdk.msi WHATPROPERTY=”I want to control the which components are installed”
Or am I off track here?
Okay, I found the answer and I was a little off track.
More background: The error occurred in the VsTemplatePathsTarget of the Microsoft.VsSDK.targets file while calling the custom task VsTemplatePaths. A little reflector (great tool!) told me that it is trying to find the registry key above.
When I tracked it more closely I discovered that the key was not present under HKLM, but was under HKCU, but reflector and some trace messages said it was using HKCU. More precisely, the key in question is present under my account in HKEY_USERs, but not the account the TFS build runs under.
It turns out, my automated install sequence was such that the build account was created after the VS SDK was installed, thus when it configured the registry settings it only did so for existing users and not the default user.
I have a Visual Studio 2005 solution that includes a setup project. The setup project specifies "d:\somefolder" as the Application Folder DefaultLocation property. When installing on a machine without any partitions mapped to "d:", the resulting installer craps out with the message
"The volume d:\ is currently unavailable. Please select another."
Trouble is, you don't actually get a chance to select a different install location (on an existing volume). What settings should I use to enable the user of the installer to change the install path, while keeping the default as d:\some_folder?
the Setup and Deployment projects from VS leave quite a bit to be desired. Every solution I am aware of will take a bit of reading and learning, as the GUI tools that make setup's for you are normally rather limiting in customization outside the realm of changing the actual look of it. I would recommend looking into the WiX (Windows Installer XML) toolset for making installations. The learning curve is one of the most user friendly ones that I have seen on the market, plus it is a free tool. As long as you have a fairly decent understanding of XML you have everything that you need in order to start making MSI's.
I suppose there should be setups available which let you change the destination.
Or you could use orca to add in a dialog box which specifies that.
Or you could pass it in as a commandline argument if the user is on a commandline interface.