My requirement is to edit a .xap file which is already in the IIS Manager.. when install another web application on IIS manager. (I want to add the end points of a web application in the previous web application .xap file)
You could write a custom action to:
Open the .xap file (it's a .zip file named differently)
Extract the file(s) that need to be modified
Edit the extracted file(s)
Re-zip the extracted file(s) back into the .xap file.
You could find the existing .xap file using AppSearch of some sort. Maybe a FileSearch element. Most of the work is going to be in your custom action though. Good luck!
Please see Mike's answer over at:
NSIS Changing config file present in XAP file i.e. silverlight component build
There's two parts here:
1) Authoring the Silverlight application to use an external config file.
2) Authoring your installer to update that config file. In this case of WiX, it's the XmlConfig element in the Util extension.
The reasons for doing it this way is to have a highly reliable installer. If you write custom actions to extract, edit and compress the XAP you'll invalidate digital signatures and introduce complexity and fragility to your deployment process. Avoiding the temptation to do all this and just use XmlConfig gives you a robust, declarative installation that fully supports the Windows Installer rollback story.
Related
Hi DocuSign CLM geeks and the DocuSign API in-house team-
Our team will be using DocuSign CLM with the DocuSign Edit add-on to easily open Microsoft Word files and save back to CLM.
We'd like to include the installation of DocuSign Edit in our Silent Mode installation configuration. We're hoping there's an msi File available for the DocuSign Edit extension? If so, please link!
Plan B- If we were to make our own msi from the available exe, does anyone have a trail stomped out for doing this? (a blog post, documentation, step by step, video demo, even a horror story)
Thanks for tips.
https://tools.springcm.com/sites/default/files/apps/docusign-edit-pc-2.01.00.exe
This is an exe that is built from an MSI, so it is an MSI.
If you want to get the MSI out of this https://www.codetwo.com/kb/msi-from-exe/:
The first method is based on the fact that most installers extract their .msi files to the temporary files folder during the installation process. To extract an MSI file from an EXE installer, you need to:
Launch your .exe file.
When you see the first prompt (e.g. a question about whether you want to continue installation, accept a license agreement, etc.), do not click anything in this window and do not close it.
Open Windows Explorer, type %temp% in the address bar and press Enter.
Sort the files in the folder by the modification date. The newest file on the list should be the .msi file you are looking for.
Copy the MSI file to a safe location before you close the installer prompt window (see step 2). Be aware that if you close the installer window, the MSI file will be immediately deleted from the temporary files folder.
The second method uses a free third-party tool called 7-Zip to browse the content of the .exe installer file. Follow the steps below.
Download 7-Zip from this page and install it.
Right-click on the .exe file (from which you want to extract an .msi file) and from the shortcut menu choose 7-Zip > Open Archive.
Do not extract any files yet. Instead, browse and look for the folder MSI within the contents. It might take some time to find this folder because it is not always located directly in the root directory (its location may vary depending on the installer).
When you locate the MSI folder, you will notice that it most likely does not contain any .msi files, but a file or files with no extensions and rather cryptic names such as 132. Despite these misleading names, these are actually the MSI files you are looking for.
Drag and drop these files to any desired folder or select them and extract them with 7-Zip. Close 7-Zip after that.
Change the names of the extracted files so that they include the .msi extension.
If there are two files, the larger one is the 64-bit installer, and the smaller one is the 32-bit version. Use the one you need.
Finally, if you want to tweak an MSI, you can use the Orca tool by Microsoft - https://learn.microsoft.com/en-us/windows/win32/msi/orca-exe
How to do Text file changes in a ZIP file in InstallShield Basic MSI project. I am not able to do Text file changes in a file which is inside a zipped file.
InstallShield does not offer this capability, at least not now. You will have to either surround the call to the text-file-changing custom action with ones that extract and replace the zipped file (the text file changes would operate on the temporary copy), or implement the whole thing yourself in one step. I'm not sure which approach will be easier.
In your situation, I would reframe the design and requirement. Silverlight .XAP files are typically digitally signed. Any attempt to modify the archive would invalidate this. It's also needlessly complicated.
Instead, change your application to use an external configuration file. native InstallShield functionality can then be used to update this file. For a possible approach, see:
Creating and Using Silverlight web.config app settings (Web.config Configuration Applicatioin Settings) or app.config application settings configuration file for Silverlight
I want to verify if certain exe files already exist in a merge module .ism (binary format). Is there a method of doing this without using InstallShield?
An *.ism file is really an MSI file with a changed extension. MSI files in turn are SQL databases stored as COM-structured storage files - a file system inside a single file with file streams for various content. This is the same format used in Office documents.
You can view MSI files with Orca from the Windows SDK: http://www.hass.de/content/how-install-microsoft-orca
Windows Installer XML (WiX) Deployment Tools Foundation (DTF) has an InstallPackage class available that exposes a FindFiles() method. This should be really easy to query the EXE. Just realize that being a merge module you won't know the full installation path as that's decided by the MSI generally.
Both of Chris's suggestions should work fine, as would using Orca. But it got me thinking there might be an even easier way using a tool called Merge Module Finder. It all depends on what you really want to do? Find files already in merge modules? Investigate what merge modules are in an Installshield file? It is not quite clear exactly what you want to do.
Though a bit clunky at times (I think the author hasn't updated it for the latest versions of Windows) it will help you look for a file in a bunch of merge modules interactively. You can also search for a registry value. Here is a screenshot:
I am looking at the cruisecontrol web dashboard. I can see one farm and one server. However, I don't see any way to add a project?
Is this something I can do with the UI or do I need to edit the config file by hand?
You'll need to edit the ccnet.config file by hand (located within the CruiseControl directory) to add projects. There are some graphical tools to help you do this however you do get used to doing it by hand fairly quickly - just have the documentation near by!
Update: An example of one such tool is http://www.codeplex.com/ccnetconfig
You can use CCNETConfig to edit the config file through an UI although it doesn't support higher version > CruiseControl.NET 1.4.
You have to basically edit the configuration file by hand, however I have it setup so that the raw config file is split into different include files, each of which is setup in my source control system. Then I created a project for the configuration, and then for the whole config. So when something changes in the config, CC.NET itself pulls out the changes, recreates it's config files and the refreshes the system configuration.
This means that anyone can edit the config (if they can access the files in sourcecontrol), and no-one has to go into the program files directory of the CC.NET machine itself.
Not sure whether this answers the question you asked, but this is how our setup works
What files can we modify so that our solution is still supported by Microsoft?
Is it allowed to customize error pages?
Can we modify the web.config files to use custom HTTPHandlers?
You can certainly edit the web.config file for your sites. The one thing that you should be aware of, however, is that when you start editing files manually on the file system, you will have to remember to manually make those changes across all servers in the farm (assuming a farm exists). In addition to this, when you edit files in the 12 hive, it's important to understand that you will be making a change to all SharePoint sites hosted on the server(s) for which the files were edited.
Personally, if I were going to create a custom error page, I would simply add a <customErrors> section to my web.config. I avoid editing any existing files in the 12 hive, but I have added files (though it's rare).
The customization of the error page is not very easy (or flexible). You can see an example here:
http://blogs.msdn.com/jingmeili/archive/2007/04/08/how-to-create-your-own-custom-404-error-page-and-handle-redirect-in-sharepoint-2007-moss.aspx
The web.config can be changed. I used my own HttpModules in addition to the original ones, but I haven't used custom HttpHandlers. IMO it should work if you don't change the original handler (i.e. if you add your handler for a specific type of file not handled by SP).
do not modify any pre-installed files in the 12 hive (Program Files\Common Files\Microsoft Shared\Web Server Extensions\12)... a service pack may update and overwrite any changes.
Anything in the Content Database (Masterpage, Stylesheets list in ~Catalogs) is available to modify (I would add, instead of update, in case a service pack changes anything) as it sits atop the file system, and is instantly available to any members of the web farm (newly added servers).
Any custom features, added to the 12 hive in the features folder, in a custom/non-microsoft folder (that is, inside the 12\feature folder, do not modify any preinstalled files, but feel free to add a folder for your feature and work within).
Custom features can be developed using the Visual Studio Extensions (VSeWSS), currently available for Visual Studio 2005/2008... benefit being that the output is a feature package (.WSP file) which is designed to be portable across SharePoint. Additionally, the .WSP files are just CAB files with a different extension, offering the ability to be explored by simply renaming them.
For site definitions, Microsoft has a good article about what is supported and unsupported. In short, the only change you can make to the out-of-the-box site definitions is changing the entry in the webtemp.xml file to hidden in order to prevent the site definition from appearing in the site template list. This is something many may be interested in doing.
You may also, of course, copy existing definitions and rename them in order to create new ones.
The complete list of supported and unsupported scenarios for working with custom site definitions can be found here:
http://support.microsoft.com/default.aspx?scid=kb;en-us;898631
Here is the closest I can find to a official response from Microsoft:
http://technet.microsoft.com/en-us/library/cc263010.aspx