I have very complex folders structure to install (dozens of folders/subfolders).
I have prepared the whole structure with heat.exe, but some folder names have "template" names instead of the real ones.
Is it possible using WiX to rename the "templated" folders during the installation?
Say I have
DirA
DirTemplate1
DirC
DirD
DirTemplate2
DirE
I can get real names for DirTemplate1 and DirTemplate2 via UI only.
Can I rename the folders after they are copied to the target?
I suppose that you familiar with WiX. And explain a few variants how it could be done.
In directory table you named needed folders with CAPITAL letters, for example DIRTEMPLATE1. Then create dialog window and set this Directory with new value. During installation directory will be created with new folder name.
(Not recommended) Create custom action which will rename needed directories at the end of installation. Not recommended because uninstallation won't delete new folders, the Repair won't work as should.
I realized that this is simply not possible to do in a right way, it contradicts the installation ideology. I would accept such answer and start thinking on a different solution. Not all problems have a solution.
Related
Is there an easy way to move a file to a different folder in dbt Cloud, without having to create a new file of the same name in the new folder, copy/paste from the old file, and delete the old file, which is a pain.
Is there a good reason I should NOT do this? I assume my refs still work as long as the filename remains the same, and I don't have any specific folder logic tied to this file.
For example, say I have my_model.sql in my 'staging' folder and I want to simply move it to my 'mart' folder instead. In this example I'd like to do this to reflect that my file is really a more 'stable' mart-type table file vs a staging view. I realize I can just change the materialization type, but I'm doing this more to organize things clearly. Thanks!
The way to move a file in the cloud IDE for dbt is not 100% obvious. You can use the rename function to move a file to another location.
Click on the drop down next to the file name, then select "Rename." That will open a file path and you can change where the file lives from there by typing in the new folder's name.
The easiest way I have found to do this is...not using DBT Cloud, but using github desktop (no command line needed).
Create a new branch
Open repository in github
View files in your file explorer
Move files or directory locally
Upload to github
Push to origin for the branch you created
Open a pull request
Merge
Depending on what the file or directory is you may find the creating a new branch and opening PR to be overkill. For my specific project there is a lot of legacy organization and models that we aren't totally sure don't have downstream dependencies, so creating a new branch for this allowed me to test run all of our models.
Hope this helps!
I have quite a few archives that I need to test.
Archives are in parent folders with many sub folders.
I am a Windows 10/11 user.
I have used 7z file manager easy enough, checks a folder for me and reports all good except for xx failed.
Then I have to manually hunt for the failed archive and move it somewhere to look at it at a later date for repair if possible or deletion.
What I would like to know if possible to do the following.
Test the archives .zip/.7z/.rar
If archive is bad, add prefix to file name bad_
Move bad_ archive to another folder.
Then I can make plans for the moved files repair or delete.
cheers.
So, I have a WIX project which is to install either fresh installations or over previous installations of a product. This product, if it was already installed, has several files inside of 3 different folders which need to be preserved. This project also needs to copy the contents of those 3 different folders into another set of folders (same content in two different locations). In order to accomplish this I have set up my project to first attempt to write into the original folders if the files don't already exist, then copy the contents of those folders. On an upgrade where those files already exist this works fine. On a fresh install the second set of folders do not get created, but all the files do.
My assumption, and I may be incorrect, is that the msi is attempting to copy the folders over before they have even been created. This would cause folders to not exist in the area they were supposed to be copied to as there would be nothing to copy from. Is there a way I can ensure the files have been generated before trying to copy them? Is there a better way of going about this that I'm not seeing?
EDIT:
I'm going to try to clear this up a little. What I'm trying to do is the following (pseudo):
1) See if an option file (hi.opt) exists in c:\options, if not create it.
2) Copy that file to c:\options\opt2015.
I'm doing this 3 times for 3 different folders. I am creating the initial files with Wix in the c:\options folder using the NeverOverwrite parameter. This part works great; the files are created without issue and none are overwritten if they already exist. Where the problem lies is step two where I'm using the CopyFile Wix command. This will only copy some of the files from the c:\options folder to the c:\options\opt2015 folder. Depending on the initial setup of the system (if the files at c:\options exist or not) some files will copy over and others won't. It's not random, the results are repeatable every time, but there seems to be no reason why some files copy and others don't depending on the initial setup of the system.
I hope this makes sense and is a little more clear, though I think it makes things worse! It is strange behavior because to me it looks like everything should just work, but it doesn't (isn't that every bug though).
Edit2:
After more work and creating a vb script which runs perfectly outside of WIX my team and I have determined that the files just are not being seen by WIX during the installation even though they do exist. We haven't found any permissions issues and the installation is running as admin on an admin account. Doing the copy via a VBS or through the Wix CopyFile command results in, well the same results; files that already exist on the system are not being copied. Any more ideas? Should we find a solution I'll be sure to post it because this is just getting weird.
I believe your installer design should work as long as you're attempting to copy the files after the InstallFiles action runs. You should be copying the files from the first set of folders to the second set of folders by doing one of the following:
Running a deferred custom action that executes after InstallFiles
Using the MoveFiles action
This is too long for a comment, but may not be an answer either....
There isn't really such a thing as "over previous installations of a product", especially if you end up with multiple instances in Programs/Features, and files that may or may not have the same component ids replacing each other - that's going to be a mess. If you need to upgrade the installed product, use a major upgrade, that seems to be where you're going with this. If you are already writing custom actions to do some of this "first attempt to write into the original folders" then I've no idea what's going on or where you doing this in the install. In general, if you need those files in the new install then add them to the new major upgrade MSI. If you need to copy the older existing files from the older product, then do a major upgrade with afterInstallExecute and write custom action code to copy them before the InstallFiles action. Or the CopyFile WiX element could do it, see the part about the element under a component with no fileid.
http://wixtoolset.org/documentation/manual/v3/xsd/wix/copyfile.html
Well, as sometimes happens, the error was entirely elsewhere. It turns out that an uninstaller for another program which was in the chain of programs which are installed at the same time was destroying the folder. Unfortunately this is what happens when a product isn't touched for 10 years. Thank you for your contributions, they were very helpful. Even though I was going down the wrong path the whole time I still made use of them in my tests and am more adamant about checking the installation order.
My problem should be plain and simple to solve, but google is not helping me today.
I need to read/write a configuration file (config.xml) and, as i see so much problems with permissions with special folders, i decided for myDocuments.
Now, from File system (Setup), I added a custom special folder (myDocuments)
added a subfolder (g1OKweb) inside myDocuments
added the file (config.xml) inside g1OKweb
What I expect, reading around, is that during the installation g1OKweb should be created if not existing or older, and the same for config.xml, but it isn't.
Does someone have any clue?
Thanks in advance
Use Directory.CreateDirectory to create the directory before attempting to access the file. This will automatically create all parts of the path that do not yet exist. If the full path already exists, it will do nothing.
When opening the file, use a FileStream constructor overload that allows you to specify FileMode.OpenOrCreate. This will succeed regardless of whether the file already exists or not.
When you have opened the file, check to see if it is empty before parsing it. If it is empty, insert your XML root element first.
How can I use MSBuildExtensionPack 's Sync task to replace all files that exist in folder A with copies in folder B? (but skip any files that only exist in B?)
Do you have to use extension pack? If that is not a requirement, you can just do it using xcopy:
<Exec Command="xcopy /yu $(SourceFolder) $(DestinationFolder)" />
Make sure $(DestinationFolder) already exists before executing this, otherwise xcopy will be displaying a prompt to create one, which is not useful for the automated build system.
The solution is simple
Use "Exclude" and "!Exists" when defining the list of files to be copied