I am working with Visual Studio setup projects to install web application. I am looking for a way to change the default physical file installation path. The end result I would like is a Virtual Directory called "MySite" that points to a local path on the server like "C:\Apps\MySite"
Is there a built-in option to customize this?
edit the project file. search for keyword 'virtual' and change the value for virtual directory.
No, it will install at the physical file installation path of the Web Site where it is installed plus the name of the virtual directory.
You have to do it with a custom action, unfortunately it's not supported as a simple setting in the setup project (as others have mentioned).
Here is an example implementation using custom action:
Allow user to set physical directory path during Web Project deployment
(a bit old but can still be useful)
Related
In a Visual Studio (2013) Deployment Project, I have a resource file (a text-file called settings.cfg) that shall be copied to the application folder. The ReadOnly-Property of that file is set to False.
After installation on the target platform (Win 7 Pro), the file is present (in the application folder), but the file may not be modified by a user without Admin-Rights, it is read-only.
Obviously in the windows-explorer you can modify the access options in the properties dialog, but you need admin rights + time/effort.
Is there a way to allow modification of the file by any user right from Visual Studio?
Editorial answer: Don't install files in the Program Files folder if you want limited users to be able to update them. There are folders like User's Application Data Folder that are actually for the user's data.
The practical answer is that there is nothing built in to Visual Studio setups to do this, so that means writing custom action code to change the access rights. That's really a "how do I change access rights on a file" question rather than a question on setup projects. I suspect the code and setup changes to move that file to a location where it just works might be easier.
Lots of examples of custom actions here:
https://www.google.com/?gws_rd=ssl#q=visual+studio+custom+action+walkthrough
and this should help too:
https://www.simple-talk.com/dotnet/visual-studio/visual-studio-setup---projects-and-custom-actions/
I have a setup and deployment project in Visual Studio 2010
The default location of Application Folder is set to C:\[Appname]
The problem is that if there is no drive C: in the machine the app is being installed, the installer will crash with an error "'xxxxxxxx' is not a valid file name" or something similar, because the installer verifies the location before the user has a chance to set the actual application installation folder. (so the default location is validated and since drive c: is missing it throws this error)
You can set the location to something like [ProgramFilesFolder]\[AppName] etc..
I would like to know what is the "macro" for the system's windows drive!
I would expect something like [WindowsDrive] or [SystemDrive] or something like that so that I could set the default location to [SystemDrive]\[Appname], for instance!
Does anybody know?
I think http://msdn.microsoft.com/en-us/library/aa372057.aspx contains the info you are looking for(for .NET 3.5, other frameworks may differ).
Hopefully the following explanation/screenshots will make it easier for future readers to set the default location:
How to set the Default location to the WindowsVolume?
Use the WindowsVolume property.
Example:
Hope this helps.
[WindowsVolume][Manufacturer]\[ProductName]
We are trying to adapt a build automation strategy for our ASP.NET web site (not a web project) in vs 2010 ultimate & tfs 2010.
Build definition makes the build and publishes the web site into folders like
<drop_folder>\<defn_name>\<defn_name>_<year><month><day>.<build no>\Release_PublishedWebsites
Now we try to delete particular files and folders from that folder. For instance the "images" or "files" folders, that we need to exclude before packaging. I know that if it were a web project, there exists a straightforward solution. We also tried to modify the build process template (xaml) file. There is a "DeleteDirectory" component but we couldn't figure out what to write to the Directory variable.
Thank you.
If you follow the XAML way, you would just have to feed the Directory argument of DeleteDirectory with the physical UNC path to the folder you 're trying to get rid of.Something along the lines of String.Format("{0}\\{1}\\{2}\\Release_PublishedWebsites", BuildDetail.DropLocation, BuildDetail.BuildNumber, Date.Now.Year)
should get you near to your target. Since the drop location of the build might be on a different machine, also ensure that the account conducting the build (by default = NetworkService) has the rights to delete folders on the target.
I'm trying to put two web projects that needs to be installed in different virtual directories in the same Web Setup Project, because they are closely related, but they have to run sepparately.
I can put project 1 in one directory, and project 2 in a subdirectory in the same virtual directory.
I've tried to add a "Web custom folder" in the filesystem editor, and configure one of the outputs to go there, then when I run the installer, the textbox for the virtual directory appears empty, and after put some the installation fails.
Can this be done? How?
Thanks a lot.
Yes you can do it. What you described here just works: One additional Web Custom Folder for each additional virtual directory and add output of the target project to each one. Make sure that the property of each of the folders is different from TARGETDIR and is all capitalized (global variable). They will have to share the same AppPool by default, though.
I want to put my dependent files in the app directory.
I seem to remember that you can force VB6 to use the files in the local directory only.
Any hints?
You may also want to try setting up Reg-Free COM for your project. There's a freeware called Unattended Make My Manifest that will do most of the work for you.
Placing component libraries in the EXE folder (with or without .local files) can be deleterious to the hygiene of target machines too.
VB6 programs will register the components here via the self-reg entrypoint behind your back if they are not previously registered. Then if the application is moved or removed you leave the user with a broken reigistration - possibly fatal to subsequently installed applications using some of the same components. This is probably fine though for application specific components, i.e. your own DLL or OCX that will never be needed by another application.
The .local trick was really not meant for use with VB6 programs and if it is used your installer needs to be aware and properly install and register the components if they are not already on the machine. It was meant as a manual hack to get around DLL version compatibility problems on individual machines, not a deployment strategy.
Move up to SxS application and assembly manifests (Reg-Free COM and more) for a better solution. DLL/COM Redirection (.local) was a good try but it has many warts.
Clay Nichol's answer about the search order is not quite correct. That search order only applies to non-COM components. I.e. only some DLLs, and not OCXs. If you register your COM objects, they will be used from the directory where they are registered regardless of what's in the local directory, unless you use reg-free COM or a .local file.
EDIT:
MakeMyManifest is well spoken of as an automatic tool for creating manifests for VB6 projects, haven't tried it myself.
DirectCOM also has fans, again I haven't tried it.
EDIT The MMM website is down. I see here that the author was having trouble with their hosting and has provided another location to get Make My Manifest - download it here.
There is a semi-automatic technique to generate reg-free COM manifests. You can create the manifests with Visual Studio 2008 (you can use a free version like Visual Basic Express Edition). Then make a couple of edits by hand to make the manifests suitable for use from VB6. See this section of this MSDN article for step-by-step instructions - ignore the rest of the article which is about ClickOnce.
It can be sort of confusing because every version of windows, the rules change. Older versions of Windows search the path before the current directory.
A simple solution without manifests:
If your executable file is A.EXE, add a (0-byte, empty) file in the same directory named A.EXE.local -- for older versions of Windows this puts the app directory ahead of the path in the search order.
Found it myself:
Windows does look in the App Directory first:
If SafeDllSearchMode is enabled, the search order is as follows:
The directory from which the application loaded.
The system directory. Use the GetSystemDirectory function to get the path of this directory.
The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
The current directory.
The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.
If SafeDllSearchMode is disabled, the search order is as follows:
1. The directory from which the application loaded.
2. The current directory.
3. The system directory. Use the GetSystemDirectory function to get the path of this directory.
4. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.
according to : http://msdn.microsoft.com/en-us/library/ms682586.aspx
But you can redirect where it looks for .dll's using a Manifest:
http://msdn.microsoft.com/en-us/library/aa375365(VS.85).aspx