John McFadyen's profileJohn McFadyens Windows I...PhotosBlogGuestbookMore  |  Tools Help |
|
|
April 21 Wise & Software Mangler DistributionSoftware ManagerThe distribute function ties in heavily with the use of conflict management. This is a very complex phase to understand and has some definite advantages and disadvantages. The advantages are only recognised if and when you are running a full conflict management solution. The main reason for the distribution phase is to allow Conflict Manager to copy files to and from other packages already in the repository. The output of this step is that all files from the MSI / MST combinations are copied from the current package to the Wise Sharepoint under the following location.
In order to demonstrate some important processes lets assume we start with the following items in our sample package
When package distribution is run files within the package are enumerated each file is then compared against the (wamdb.idx). If the file does not previously exist it will be copied into [000]001\FILE1.DLL. At this point our applications sample information will now look like this.
Note: The change in the WiseSourcePath table. The change in the WiseSourcePath table has a potential negative impact but it is done for a very specific reason. In my opinion the WiseSourcePath table should not be modified and instead Wise should of created a new table such as WiseSoftwareSourcePath or something similar. (however that is not the case so we have to cater for the negative impact of this step.) If we then run the same distribution on another similar package “APPLICATIONB” and assume this application also contains the same FILE1.DLL (version 1.0) the distribution function will check the Repository Database and find that the file already exists.
If the file does exist the files version would be checked, where the files version was the same no files would be copied to the repository, however the WiseSourcePath entry for “APPLICATIONB” would be updated to show the same after distribution path as APPLICATIONA in the above example.
If the file does exist and the file version is different from files already stored in the repository. Then a new folder will be created and its number incremented from the folder that last contained a copy of the file with the same name.
The intention here was to ensure that all APPLICATION FILES for each application in the Software Manager will be available and relative to all packages currently imported in the software Manager from the WiseSharePoint. However each file will only ever be referenced once regardless of how many applications contain the file name. However if more than one version of the same filename exists you will find multiple folders housing each of the individual copies of the respective files. Therefore the folders with the lower numbers are more likely to contain more files from the various applications which have already been through the Wise Distribution phase. At this point I expect most of you are reading this quite confused or even wondering why would Wise bother with such a step. The answer to that question is as complex as the question itself. If you consider what conflict manager is trying to do, it is basically trying to ensure all applications are sociable with all other applications already imported into the Software Manager. In order to do this there is likely going to be a time where you would like to switch files from one package to another. To cut a very long and complex story short this is why the distribution phase is run. It basically allows functionality within Conflict Manager to be enabled, this functionality allows the user to copy files from one package to another package. Prior to distribution the WiseSourcePath table has entries which are relative to the current working file. For example APPLICATIONA.WSI. All files relating to APPLICATIONA are present in the folder for APPLICATIONA. (no rocket science here) However after distribution each file entry in the WiseSourcePath table will look similar to this.
Note: ..\ means that the package will step up a folder from its current location. So if we are working on APPLICATIONA which is in the WORKING FOLDER APPLICATIONA in this example. If we step up 2 directories (I.e. ..\..\) we will be at [SharePoint] from there the remaining path of 000\001 is easily found from the SharePoint location. If we are working on APPLICATIONB which is in the WORKING FOLDER APPLICATIONB in the same example. If we step up 2 directories (i.e. ..\..\) we will also be at [SharePoint] from there the remaining path of 000\001 is easily found from the SharePoint location. Basically what I am trying to say is, if we are working in a package directly under the projects folder no matter what the package location is 2 folders up is [SharePoint] in effect this means that each package that has had distribution run on is is now relative to all other packages within Software Manager. This is a very important part of understanding conflict management in its entirety. Conflict ManagementUsing the same example applications mentioned above, if we now look at this from the perspective of the Wise conflict management tool we will see a different picture of why this is done. For example: If we assume now we have imported both applications into conflict manager. Remember that both packages had FILE1.DLL present as such we would see that each of these applications would conflict against each other as they both had the same file name existing in various locations. The following picture is taken from an actual conflicting application. The top window is the currently selected package. The bottom window is all other packages in the Software Manager that conflict withe package in the top Window. The circled item is the files in the currently selected application which is conflicting with other applications. The items circled below are the other applications in conflict manager which are actually conflicting with the item which is selected in the screen at the top section. The two buttons in the middle are used to swap files between other packages. Note: This item is only available if the distribution option is used, the view depicted here is from a package which has not run the distribution phase
Selecting a package from the view on the bottom will allow the grayed out middle items to be selected. Then selecting either button will allow you to move dll’s from one package to another package. Note this heavily integrates with the items listed in the WiseSourcePath tables earlier in this post. Pushing this "Copy Up" or "Copy Down" presents the above item. The two checkboxes perform the following.
So for the purpose of explaining Conflict Management processes lets assume that the TOP window is APPLICATIONA and the BOTTOM window is APPLICATIONB. If we select the "Copy UP" option we are effectively saying lets copy the file from the application selected in the BOTTOM window, in this case APPLICATIONB into the application selected in the TOP window. In this case APPLICATIONA. Prior to distribution you will recall we have this information.
After distribution we had this information.
Based on this if we are Managing Conflict management for APPLICATIONA you will note our Working Directory is
We are however interested in copying file from APPLICATIONB into APPLICATIONA. So in order to achieve the copy APPLICATIONA reads the WiseSourcePath table of APPLICATIONB. Prior to distribution the WiseSourcePath table for APPLICATIONB reads as:
The current working directory is [WiseSharePoint]Projects\APPLICATIONA as such Wise will look into
After the distribution phase the WiseSourcePath table reads as WiseSourcePath = ..\..\000\001\FILE1.DLL. So with a working directory of [WiseSharePoint]Projects\APPLICATIONA\..\..\000\001\FILE1.DLL we will find the path to the source files for APPLICATIONB. Regardless of the application selected if the distribution phase is run all applications can find files from all other applications. Well that about wraps the distribution phase up, its very complex to put into words I would be interested in any feedback about this document. Its hard to understand implement and even harder to write about it. This is some pretty smart work on behalf of Wise. I hope this can help somebody struggling with the principals of Software Manager. April 16 Automating Software mangler importsTechnorati Tags: Wise Package Studio,Software Manager,Automate Software Manager,Import using ini file Ok so someone on the Wise / App deploy forums was after this stuff. Here's how I automated my software mangler imports using Wise. The code is pretty self explanatory so I won't go into detail unless someone asks for more info. ' **************************************************************************** option Explicit const ForReading = 1 Dim sobjArgs, sobjShell, sobjFSO set sobjArgs = Wscript.Arguments sstrMSI = sobjArgs(0) sstrServerName = "WISESERVER" set sobjFSO= sobjFSO.CreateTextFile(sstrProjectDir & "\" & sstrProject & "MSI.in sobjFSO.Writeline "[Database Info]" Output result is something along the lines of this. [Database Info] |
|
|
