I created a Documentation folder in my project, and added the user guide, a pdf file, to my project (as content, copy if newer)
Using a click-once deploy, the file is copied - but casual users will not be able to navigate to its location using explorer. How can I configure the deployment to make it easy for the user to find this file when they want to read it?
I do not think there is a ClickOnce solution to this, you need to create the folder after first run (for example ProgramFiles/Appl) and copy the help file to the folder manually.
Another way to handle this is to copy the file to MyDocuments/yourappname/appdata/ when your application starts up or when the user asks for hte file, and then direct the user to it there.
Related
I would like to create a Build Definition inside TFS 2012 Express which will simply copy all files within my project source tree to another folder on my drive. Just to underline - I do not want the build output to go to another directory - I want the source files themselves to. The reason for this is I have IIS pointed at a specific folder, and I want the build to copy the latest asp and aspx files to the IIS hosted folder.
I am not sure of the intricacies of doing this, I did find : http://toadcode.blogspot.co.uk/2008/06/copy-multiple-files-via-tfs-build.html articles like this but I simply need a more direct list of what I need to do from somebody who understands this area.
Basically - when the build is queued, all I want is to copy my project source files to another directory :). I think this can be done by editing some Build.xml file...but when making a build definition I dont seem to be given the freedom to do what I would like to!
I think what I am looking for to alter my DefaultTemplate.11.1.xaml file to alter the build process which will let me run this / or a batch file after the build process completes?
My TFS build process edit screen looks like this:
Using this post as a guide on how to start editing TFS Build Templates (or the Wrox TFS 2012 book), you need to make the following changes:
Locate the Copy to Drop Folder Activity:
Drag in a "CopyDirectory" activity under the "Drop Files to Drop Location" (from the Toolbox under Team Foundation Build Activities):
Goto the Properties Window for the new Activity and set Source and Destination as follows:
Destination: Path.Combine(BuildDetail.DropLocation, "MyOutputFolder")
Source: Path.Combine(SourcesDirectory, "MyFileFolder")
You may need to repeat this if you don't have all your files in one folder.
I actually put something together for TFS2010 and 2013 (not 2012, unfortunately) a few weeks ago that does exactly that. Basically, anything in the workspace you define for your build just gets shoved over to the drop location.
Here's a link to the blog post where you can download them:
http://www.incyclesoftware.com/2014/06/deploying-uncompiled-resources-release-management/
For the record, I strongly recommend against using a build process template to deploy software. Don't try to overextend the build... its job is taking stuff from source control and compiling/packaging it for deployment. Use a real release management solution to actually handle deploying software.
Add a bat file to your source folder. within the batch file add an xcopy %1*.* TargetLocation.
Add an invoke process activity to your workflow, somewhere near the end. call the bat file and pass it the SourcesDirectory.
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.
we are making an Application for OS X, however, when the .app is copied on another MAC, we have problems with reading and writing files
on one MAC, everything works great from the start...
the other one will not write certain files and another 2mac will not write certain different files
if i go to show application contents and wants to edit the file by myself, i get a writing permission denied
how to distribute an MAC application so there are no such issues? so all files can be read and write by the current user
does there have to be some authorization or code sign, or smth. different in this form, in addition to normal code?
thank you
It sounds like your application tries to write files within its own application bundle. The correct solution here is: DON'T DO THAT! The only time your application bundle should be written to is when it's installed or updated.
Files that the application needs to write to should be stored in the user's home folder, generally under ~/Library. See this note in Apple's dev docs.
Preference and settings files in ~/Library/Preferences/<appbundleid>.plist; use NSUserDefaults.
Data the app manages for the user in ~/Library/Application Support/<appname> (the docs say to use the bundleid, but everyone -- Apple included -- uses the app name instead).
Cache files in ~/Library/Caches/<appbundleid>.
Temp files, use NSTemporaryDirectory
If you need to share settings & files between users, that should generally go in /Library/Application Support/<appname>, except that you really shouldn't be doing that at all.
In the past I've always used PackageMaker to create installers. An installation package can authenticate with root privileges so you can set permissions after the install. I don't have it in front of me right now but if you look around you should be able to see a Post-Installer script line. Write a shell script that manually sets the permissions of each file you have in question and then have the package execute that script after the install is finished.
You can find PackageMaker at /Developer/Applications/Utilities/PackageMaker
this may be a stupid question... but I have created a setup.exe using Installshield that installs my application. I cannot use an MSI because I want to include prerequisites, like for example .NET 4.0 framework web install.
So, I put this setup.exe on my web site somewhere, but when I try to download this I get 'The page you are requesting cannot be served because of the ISAPI and CGI Restriction list settings on the Web server.' Obviously a security is going on that makes it impossible to download executables.
So I zip it to setup.zip, and now it can be downloaded.
My question is: what is the best way to distribute such a setup via the web? Is it acceptable to make it a zip file for users to download (because then they have to unzip it first), or should I just allow an executable to be downloaded?
I've seen this practice for some products and it's always annoying. Why would you give me a ZIP file which contains a setup file? There are no advantages, but a lot of disadvantages:
I need to perform an extra step to extract the ZIP
I need twice the disk space (the ZIP plus what's inside it)
Most users don't see a ZIP file as an installer, they are used to "setup.exe" or "setup.msi"
The correct approaches are:
configure your website to allow EXE file downloads
or
distribute a ZIP which contains your application files (instead of using a setup file)
We have different dev environments between developers here. When I build, I want my compiled files to be copied to a bin folder located in C:\Web\bin\. Another developer may want those files dropped in C:\Web_2011\bin\.
Using Visual Studio 2010, the way we work this now is to run a BAT file with the directories defined as parameters that need to be changed if pulling from another developer's branch.
Is it possible to store a solution-wide parameter, (in a .user or .suo file maybe,) to define where a developer wants to drop his builds?
You could do it through the project file (.vcxproj for C++ project for example).
The simplest solution would be to add a Custom Build Step that runs some batch file. This batch file could check the current user name and copy the files based on that.
(An even simpler solution would be to run a user specific batch file from his local disk)
If you really want the fully fledged solution that will allow you to save this data to the user file, you can do it by editing the project file and adding a PropertyPageSchema element that extends VS property pages with another parameter (your destination directory). You can define the Persistence attribute of DataSource element as "UserFile" and the data will be saved on your .user file. You will need to add some target that actually uses this data (copies files to the directory specified).
For more information, read about msbuild and PropertyPageSchema.