This is related to Wix:
I have a situation in which I have to deploy a file into multiple directories whose values being fetched from registry. Now these directories could be from 1 to many.
And I don't want to create too many Directory entries whose values would be determined at runtime.
Can we call a custom action in a loop which would be detecting the target Directories and setting-up our target folder values?
I know we can do such copying inside a Custom Action. But I'm looking for a way to do this via WIX entries.
I was reading about DuplicateFiles Action but not getting some proper methodology to achieve my goal.
Thanks a lot
The WiX element CopyFile maps to the DuplicateFiles action. You can use AppSearch to set properties and then use CopyFile to duplicate a file to a directory. DuplicateFiles is smart enough to not do anything if the property is null.
If the number of copies is known when you create your installer you can just do that. If you think it's going to somehow be more dynamic at runtime, you can write a custom action that emits temporary rows to the DuplicateFile table that way DuplicateFiles and RemoveDuplicateFiles still does the heavy lifting.
You can use the principals described at Dynamic Windows Installer UI.
Related
I manage a team of designers working on Indesign.
When we work on a project, it often happens that a designer has to work on the project of another. We work with Dropbox for Business.
But when we take the work of another designer, there is often missing links and fonts.
Is there a plugin or a way to develop a plugin that would allow, when we create a new indd file (or for the protection of the same file):
Automatically create a "Links" folder and another "Document fonts" at side of the indd file
Systematically add a new link or new typography in the corresponding folder?
To simplify: each action on font or on a link, make a kind of "Indesign Package" in real time?
If this is not a solution, do you have any solutions to meet this need?
I don't know of a specific script or plugin that does this.
However, it should be possible to write a script with an eventhandler with a beforeClose event that runs certain script commands every time a user closes a document (or even every time a user adds, changes or deletes a link). At this point the script could run some copyLink commands on all the images and fonts (?) placing them all in the folders next to the document.
The whole script could be made a startup script, so it becomes active anytime any user runs InDesign.
(I'm actually not sure, if fonts can be copied so easily. Worst case scenario would be that the script would need to run some packaging command to gather the fonts somewhere, copy them over to where you need them and then delete the rest of the temporary package.)
Did you consider Creative Cloud Libraries ? They are meant to allow sharing assets within a team. Apart form that, you users would need to have a same access to the file system (a common drive letter for the network path for example).
Another solution would be to use a DAM solution so users would link files from the DAM.
Eventually, you could sure think of a script as mdomino offered.
I have to implement a installer which has a lot of files and also a huge directory structure. And to implement all of the required components manually, I have to spend a lot of time in it.
Is there any other, shorter way to accelerate it?
You can use Wix Harvest Tool (Heat) for automatic .wxs composing. Usage (from community tutorial):
heat dir folder -cg SampleGroup -out SampleGroup.wxs
will harvest the folder specified recursively, creating a Fragment consisting of a
ComponentGroup with the name specified with the -cg switch. The group
will contain as many components as there are files, each component
having a single file inside, as the rules dictate, and will assign
uniquely generated component, directory and file identifiers that
remain the same when regenerated on the same input set. GUIDs will not
be generated (only a placeholder text) unless explicitely instructed
to do so by the -gg switch.
There are also tons of answers on SO, just search by 'heat' keyword.
Is there a recommended way to initialize the data in Isolated Storage for Windows Phone 7 application before it is run for the first time? Right now the best solution I can think of is putting a flag in IsolatedStorageSettings and checking for its presence on in the application Launching event. If the flag is not present I initialize several objects in code and save them to Isolated Storage and set the flag so they are not set the next time the application is run. Is there a better way to do this? Should I add the objects in serialized state as some kind of resource or it is acceptable to initialize them in code? I expect that they would require like a thousand lines of code.
Well if you can create your files and add them to the project. And if you are sure that you will not be editing your files than just keep them like that. The files will go into your installation folder.
Or if you think that you are going to edit them and want to keep the changes saved, than copy them from the installation folder to the application storage folder.
Here is a link in which a database which was added as a reference to the project is copied from installation folder to storage folder of the app.
http://msdn.microsoft.com/en-us/library/hh286411(v=vs.92).aspx
Do the same for your files and everything will be fine.
The second part of your question. Well after this just check for one file/folder in the app storage folder and if it says yes it is there than do not copy your files from installation folder to application storage folder.
And if you are trying to make the files when the application launches than just add a check before the creation code is run. Where you will search for a file/folder existence. And if it exists do not run the file creation code.
I'm thinking of Mask as in a circuit Mask (I think)- let me explain with a handy chart
The common source would be physically in c:\source
Instance A would be physically in c:\instanceA but initially have nothing but symlinks to everything in c:\source
Instance B would be physically in c:\instanceB but initially have nothing but symlinks to everything in c:\source
As you made changes to Instance A and Instance B, you would have create a mask that would hide files from CommonSource if they were deleted from the Instance folders and create a new physical file in the instance directory if an existing Common Source file was modified.
New files would live in the instance folders but never make it back to the Common Source.
This type of setup would be very useful for a project where I want to do many different types of small tweaks to multiple instances where distinct threads would work on distinct instances.
I know about symbolic links but they fall short in the case of modifying a file.
Is there anything that can accomplish this? If not, should I try to make this and patent it? Seems like a good idea to me.
I would be on Windows Server 2008 or later.
Fearing I'm stating the obvious, but git is one tool that can be used to achieve this behavior.
Make your "Common Source" a git repository
Clone the repository twice to "InstanceA" and "InstanceB"
In each instance, check out a new, unique branch
As changes are made in "Common Source" you can merge those changes into "InstanceA" and "InstanceB" while maintaining the "MASK" (changes to the branch) you've created for each.
This has the added benefit of allowing changes from "Common Source" to be pulled as you wish instead of having changes to "Common Source" pushed out to each instance (something I imagine would be less desirable and more prone to error).
You're looking for a union mount. Unfortunately, I'm not aware of any implementations for Windows, but there are several available for Linux, notably UnionFS.
In general they are used for making a read-only filesystem look like it's read-write: typically on live-CDs.
Since Windows 7 you can use libraries, which will allow you to include files from more than one physical location.
Windows 7 also include VirtualStore type of folder (for example, when creating or modifying a file in Program Files folder, it will actually be created in a user specific folder:
C:\Users\user\AppData\Local\VirtualStore. However - I don't know how you can create this type of folders yourself, and also, as far as I know, you can add and modify files, but not delete files in that way.
You'll want a versioning control system that supports per file checkout and permissions. Then you just need to set up a simple API converter that takes file-system commands and converts them to versioning control commands.
Delete -> disable permission to access file.
Directory commands should look for local copies and things you have permission to access.
Open -> grab local copy, on fail check-out file from repository.
Save -> disable permission, save local copy. //Avoid duplicates being seen.
Close without saving -> if permission to access from repository, delete local copy.
((By the way, this storage optimization seems somewhat spurious for versioning. Disk space is relatively cheap.
If your interest isn't in versioning, I'd suggest looking into separating out the information you would potentially want as volatile and creating configuration files for each branch. This, of course, requires a predictable pattern to the changes.))
IBM Rational ClearCase is version control system which does file-mask-like behaviour. It is known as MVFS: MultiVersion File System and can be mount to a workstation like a ordinary network drive.
ClearCase server (aka. VOB) you can store several versions of the same file, each on different code branch. The sets of files visible by user are called views. Each view has a configuration (aka. configuration specification), which defines what files and versions are visible for current user. Typical file looks like this:
# From wikipedia: http://en.wikipedia.org/wiki/IBM_Rational_ClearCase#Configuration_specifications
# Show all elements that are checked out to this view, regardless any other rules.
element * CHECKEDOUT
# For all files named 'somefile', regardless of location, always show the latest version
# on the main branch.
element .../somefile /main/LATEST
# Use a specific version of a specific file. Note: This rule must appear before
# the next rule to have any effect!
element /vobs/project1/module1/a_header.h /main/proj_dev_branch/my_dev_branch1/14
# For other files in the 'project1/module1' directory, show versions
# labeled 'PROJ1_MOD2_LABEL_1'. Furthermore, don't allow any checkouts in this path.
element /vobs/project1/module1/... PROJ1_MOD2_LABEL_1 -nocheckout
# Show the 'ANOTHER_LABEL' version of all elements under the 'project1/module2' path.
# If an element is checked out, then branch that element from the currently
# visible version, and add it to the 'module2_dev_branch' branch.
element /vobs/project1/module2/... ANOTHER_LABEL -mkbranch module2_dev_branch
I'm putting together a simple help system for my WPF app using XAML FlowDcouments (just .xaml files, no code-behind). I've simply added them to my project with Build Action = Resource, and I can load and display them as required.
Now, I'm trying to make it a bit more flexible, in that after the installation of the app, I want the user to be able to download additional (or newer versions of the existing) FlowDocument XAML help files. Given this, I'm now wondering where the best place to store these files is. A few questions/ideas:
Can I leave them as resource files, and overwrite or add new files as required? I can't find a example of how to add/edit resources at runtime on SO/Google. Is it even possible?
If not, is there a recommended location to store these files? They should be available to all users, so they can't go into the User's directory - they would have to go in the program directory. Does the program directory have write-access (I remember having issues with that before)?
Any other ideas?
Thanks.
The resource files are embedded into the executable and therefore you cannot change them.
As for a common place to put your downloaded help files, you cannot store them in "Program Files" since you would need admin privileges to write there.
I suggest you put them into SpecialFolder.CommonApplicationData (see http://msdn.microsoft.com/en-us/library/system.environment.specialfolder(v=vs.80).aspx), which is defined as "The directory that serves as a common repository for application-specific data that is used by all users."