If I use the publish feature in VS2008 (I think it's called ClickOnce install), and then install the published application in another computer, where are the files copied?
In other words: If I need an auxiliary file (a .txt file) in the same path of the assembly, where do I have to create it?
Thank you.
You should have specified the location when you published the application. Just note down that folder.
If you run the wizard again for the same project it should have remembered the location and the folder will be pre-filled on the form.
I've used this and I specified a location on my hard drive for the Publishing Folder Location. This folder contains the following files:
publish.htm
setup.exe
[application].application
It also contains a folder called Application Files which contains the files needed to build the installation - the exe, the manifest, other dlls and external resources.
I then copy the three files and the folder to the web location specified by the Installation Folder URL.
If you're talking about where the files get installed to then they're in:
C:\Documents and Settings\[user]\Local Settings\Apps\2.0\H165QZM1.QBE\0OAEZTRX.Y3N\[some truncated version of the exe name followed by a GUID]
Which isn't the most obvious place. I should also point out that the folders H165QZM1.QBE and 0OAEZTRX.Y3N will probably be different on different machines, but the only other folder under C:\Documents and Settings\[user]\Local Settings\Apps\2.0 is called Data so they should be easy to spot.
Is the application available offline or online only? My experience is online only and in that case I believe it installs into a temp directory. Can you include your auxiliary file as part of the application files? This may help as well it talks about including data files which can be of any type.
http://msdn.microsoft.com/en-us/library/d8saf4wy.aspx
http://msdn.microsoft.com/en-us/library/6fehc36e.aspx
Related
I have moved binary files into the project under the bin folder to avoid publishing the same binary files twice since one of the binaries is huge; i.e. 15MB.
This was originally in a separate Includes folder. So the files were being copied twice to the publish folder.
Is the bin folder the correct placement for these or are there other steps I should take?
Edit:
Sorry if I gave a poor explanation (and original title). I've changed the title; this was "Where should static libraries (3rd party DLLs) be kept in Visual Studio?", and is now, "How can I avoid publishing the library folder in a Web Publish?"
As mentioned, I originally had a separate folder named Includes. When I did a Web Publish, each of the DLLs are published twice; one into the bin folder, the other into the Includes folder. In this case, I am publishing at least an extra 15MB of unnecessary file space. Normally, not a big deal but if I am on a very slow connection, I'll need to wait longer to deploy the project to its environment.
I moved the DLLs back into a separate folder but the folder is still published along with the bin output folder. I did this to see if the placement of these files would set their properties differently.
I have tried various settings for Build Action and other property settings for these libraries without success.
Is there no way around publishing the DLLs twice?
If these files are part of the overall source of the system (not necessarily as source code, but as source-control-tracked artifacts nonetheless), then you probably don't want to keep them in the output folder for the build. The output folder should be transient and shouldn't be tracked in source control.
Keep 3rd party libraries in a library folder. The folder structure in source control might look something like this:
/
--/lib
--/Project1
----/SomeSubFolder
--/Project2
----/Images
----/Styles
and so on.
Each Project would have its own bin folder when it gets compiled, which itself may contain other folders for types of compilation (Release, Debug, etc.). But you don't want those build artifacts tracked in source control or in any way interfering with what's in source control.
The projects would reference their library dependencies, and at build time those dependencies would be copied to the output folder to be used by the application runtime.
I have written a Visual Basic.Net application in Visual Studio 2012 Ultimate. When this application is installed to the Program Files folder, when files are saved, they are located in this location:
C:\Users\[Username]\AppData\Local\VirtualStore\Program Files\[Company Name]\\[Application Name]
How can I specify to save the files in the following directory:
C:\Users\[Username]\AppData\[Company Name]\\[Application Name]
folder (basically, not the VirtualStore folder)?
Do I need to register this application within Windows to do this?
Thanks in advance
First, what instalation software are you using?
Second, if you're going to save your app files in the AppData directory, then you should really choose to save your app in either the, Roaming, Local, or LowLocal directory. It isn't "proper" to start making new directories where other directories are available to use, especially since the Roaming, Local, and LowLocal directories were more-or-less made to hold application's data (which is why the parent directory is call "AppData").
I am creating a WIX installer project. During one managed customized action, I need to create a file (other than the deployed files specified in the components of WIX) in the installation folder, which by default is the Program Files folder. I am experiencing the "Access denied" problem in Windows 7. After some searching, I found out that people say it is not advisable to create files into Program Files folder. Instead, try to create files into for example AppData folder. For example, see this link:
C# Access denied to path in a Windows Application
But my question is, the generated file is crucial to our SW, so it must reside in the installation folder. Isn't it the target of SW installation, I mean, to create file in most of the cases Program Files folder? Does it mean the only files should be added into installation folder, during the installation, are the deployed files (basically the targets of XCopy)?
My file can't be made deploy-able in the WIX, i.e, it can't be made ready before the installation. So what's the proper way or best practice to handle such situation: a file must be generated during the installation, into the installation folder. It is not some log file that I can put somewhere else. I tried to create a Permission element in WIX for the INSTALLADIR, although it seems to be against the rule mentioned in the link, but it still failed. Thanks!
UPDATE:
Based one MichaelUrman's commen, some more information. The generated file is needed after the SW is installed and necessary during normal launch of the SW. And I think it needs to be modified during normal use after the installation. And as I mentioned my a comment to #caveman_dick answer, my CA is actually in commit phase, I don't know whether there is any difference between it and normal deferred CA
Set the custom action to Execute="deferred", that will run the command elevated and should give it the required permissions to create the file.
Since you need to update that file from the main application, and I'm assuming your application does not require elevated privileges, you have three options.
The first is the worst: without a manifest, your executable's attempts to write to the Program Files folder will typically result in it being redirected to the Virtual Store (see File Virtualization). It sounds like this isn't happening in your case, so you can't use it.
The second option is to modify the application to store this in an appropriate location such as the ProgramData folder, or Common Documents, or (if appropriate) a per-user location under LocalAppData. This is typically the best approach, but has the highest development costs.
Finally the third option is to create the file and change its permissions (or in some cases to change the permissions on the folder containing the file), allowing limited users to modify this file. See LockPermissions or MsiLockPermissionsEx for the Windows Installer way to approach this. Change the permissions on as few files or folders, as restricted as possible, to keep the system as safe as possible if you go with this option.
I'm working through installing the N2 content management framework in an ASP.NET website project.
The instructions at http://n2cms.com/Documentation/Content-enabling%20an%20existing%20site/The%20first%20content%20class.aspx recommend I create a lib folder to hold the required dlls. The very next step asks me to reference those same dlls - which will presumably add them to the bin folder! Thus my project will contain duplication copies of the dlls.
Can anyone suggest why this recommendation has been made?
Thanks
David
The project will not contain duplicates. The bin folder is where the output goes, but it is not considered part of your actual project and is not checked into source control.
By placing the DLLs in a lib folder, it makes it easier to distribute them with the source of your application and ensures that anyone else who gets a copy of your code, whether you send it to them or they grab it from source control, has the necessary DLLs to run the application. It also ensures that they are use the same version of the components that you used to create the software. If the DLLs require licensing, it can be a different story because anyone who wants to compile the project would need the licensing component for the DLLs installed on their workstation.
Basically, the main benefit I see is that it keeps all components used by your code in the same place, making your project one whole unit.
If you add the DLLs to the bin folder, then one day decide to clean your project, they will disappear... So it's good practice to keep your reference DLLs out of the bin folder.
Actually there's quite a few ways the DLLs can be accidentally removed from the bin folder. Just think of the bin folder as a transient location, the contents of which can be refreshed at a moment's notice.
During the build process all relevant files will be copied to the bin folder, including config files, content files marked for copy to the output folder, and of course, any referenced DLLs marked for Copy Local.
If the duplicate locations bother you, you can keep the DLLs in another folder, and just add the containing folder path to the PrivateBinPath of the current AppDomain, which will ensure they get loaded without requiring the Copy Local property.
When I deploy applications to our BizTalk server, we deploy to a test machine, add all the necessary resources and then export an MSI that we import on our production servers (we have two). The other day I noticed that there are dozens of folders on our production servers that appear to be copies of each developer's source code location.
For example:
C:\Development\MyProject1
C:\Projects\SomeProject
C:\Users\Ryan\My Documents\Visual Studio Projects\Another Project
Many others
They're all projects we've deployed to BizTalk and the folders don't contain source code, just the "Deployment" folder of each BizTalk project with DLL files in it. However, I thought the MSI packages were adding the DLL files to the GAC, or at the very least, were putting them in the MSI install target folder (all MSI files are installed to "C:\Biztalk\ProjectName").
Can somebody shed some light here? Are these extra copies safe to delete, and will that stop my BizTalk applications in their tracks?
(I just reread your question and see that my answer may need some more context. Before you deploy the next time, have the developers follow the steps below so that you won't end up with the folders you mentioned in your question.)
You have control over the installation folder - you just need to change your resources' destination using BizTalk Administrator. You can also control installation in the GAC.
Use the following steps to modify the installation folder (things get installed in the folder that the user specifies when running the MSI):
In BizTalk Administrator, under your Application's Resources folder, review the values under the Source and Destination Location columns - you'll see folders and drive letters that exist on your system.
For each item in the list, right-click and select Modify
Change the Destination location - the path part of the location - to **%BTAD\_InstallDir%** (include the % symbols and separate the last % from the file name (probably a DLL) with a back-slash character ( \ ). So, it might look similar to this when you are finished: **%BTAD\_InstallDir%**\MyStuff.DLL
Export your application
Run the MSI on your target systems - things get installed in the folder that the user specifies when running the MSI
This is the essence of the solution - I coincidentally wrote a brief blog post about this last month.
I wouldn't delete them until you did a redeployment. BizTalk is remembering the location the resource was initially added to the resource meta data source. For purpose of generating an MSI you should add the resources from where you want them to reside on the production server.