Here's my requirement:
1. I want my installable to have a custom license agreement
2. run another package as part of the installation
3. let the user have an option of running the app on start-up
What should I use, create a dmg or use PackageMaker available with xcode? Are there any good web pages showing how to use PackageMaker?
Thanks.
They serve different purposes:
DMG (disk images) is just a container file format to solve age-old issues with multi-fork files and transfer protocols and intermediate hosts that can't handle them, by not relying on them in the first place. In addition, the disk images can use internal compression. Your users will thank you for not confusing them with file wrapped in file wrapped in file (although disk images themselves take some explaining initially).
PackageMaker is a full-fledged installer package builder. You can customize the installation process and locations, do sub-installations and pretty much anything else you could possibly need. If your installation entails more than just dragging and dropping an application bundle into place, this is the one to go with.
From your requirements, the choice seems obvious. Since an installer package is itself a bundle, I'd say: create an installer package with PackageMaker and put it in a compressed disk image. Distribute the disk image to your users. It just provides a nicer experience.
Related
I have a WPF project which has a resource (videos) with over 24 GB, I have set the configuration to Copy if newer in Visual Studio 2017. I want to generate installer files that will include all my resources (videos) that are inside the debug/bin folder.
I have tried Microsoft Visual Studio installer extension but that generates only 700Kb of exe file.
Please suggest.
Online?: In all honestly, I would check if it is possible to put videos like that online (even Youtube?) instead of bundling them inside a setup - especially if you might ever want to update them. This will require a server and bandwidth (unless you Youtube it), but it will also allow smaller setup size which is very desirable (build turnaround time and overall messiness of dealing with large files) and also much better maintainability over time for the content (you can update the videos for all users instantly - and you can even take videos down that you suddenly don't want distributed anymore, or you can replace the videos with lower or higher resolution versions as you see fit). Further you can track what videos people actually view, and you can gather feedback from the users if you provide a means to do so. I am not sure of the copyright and legal issues involved, but if these are your videos you should be fine. How about using YouTube for low-res versions? And then a separate gigabyte-size setup for high-res versions? You could include some very low-res versions of the videos in your setup if the online versions are at risk of disappearing and you want no local full-size installation.
Large Files Concerns: It is also important to point out that you can't store a file that big on FAT32 partitions and other file systems might have problems as well. Large files are painful. There may be caching features in deployment tools now that I have not used - I am pretty sure WiX has this, and I think the other tools do as well. Maybe Bogdan or Urman can comment?
Deployment Tools: I have an ad-hoc summary of different deployment tools here. WiX is free and open source, most of the other tools are commercial and very good for most deployment tasks.
Here is a WiX quick start piece
Here is an Advanced Installer Portal & User Guide
Installshield 2018 online documentation
PACE Suite PDF (large download)
VS Installer Project Limitations: Visual Studio Installer Projects have many limitations, here is a summary of some of these limitations.
External Source Files: MSI supports external source files. All deployment tools - including the free WiX - should be able to support this, but I am not sure that Visual Studio Installer Projects supports it. Using this approach you can rebuild test and QA setups quickly without compressing the whole video folder for every build - vanquishing the lunacy of large builds. Woho! This drastically improves turnaround time. For the final release you can compress everything - if need be.
I have never used this much, but in WiX it would be something like:
<Media Id="1" />
<..>
<Component Feature="MainApplication">
<File Source="TestLicenseAgreement.rtf" Compressed="no" />
</Component>
I am not sure if you can have the file remain where it is, or if it is copied to the build output folder at all times.
Need-For-Speed: Some further options here (availability differs between tools): Speed up Build-Process of WiX-Installer (shimming files, light compression, release flags, compiler options, splitting large setups into prerequisite setups, etc...).
Twist to the standard “SQL database change workflow best practices”
Background
ASP.NET/C# Web App
MS SQL
Environments
Production
UAT
Test
Dev
We create patch scripts (XML and sql) that are source controlled in Mercurial. We have cmd line utility that installs patches to DB (utitlity.exe install –patch) from a Release folder the build packages. Patches have meta data that helps with when patch should run and we log patches installed in a table in the target DB. All these were covered in the 3 year old question:
SQL Server database change workflow best practices
Our Problem/Twist
I think this works well for tables, views, functions and stored procedures. We struggle with application configuration data. Here are some touch points on application configurations.
New client. BA performs system study and fit analysis. Out of this comes a configuration word document of what application configurations need to be setup. Note some of these may also come in phases over time. We need to get these new configurations into the system for the developer and client UAT.
Developer works on feature request or bug fix. A new configuration change comes out of that change. The configuration needs to make it into the system for testing and promotion to UAT and up.
QA finds that the developer missed an associated configuration change. That configuration needs to make it into the system for promotion to UAT and up.
Build goes to UAT. Client performs acceptance testing but find they really want to change another unassociated configuration and have it promoted with the changes. In other words they found they want to change a business process by a configuration. The configuration needs to make it into the system for promotion to PRD.
As the client operates in PRD they may tweak application settings. These configurations need to make it into the system for future development and testing.
The general issue is making sure we are accounting for all the configurations and accidently not miss any during promotions which causes grief.
Our Attempts At A Process
a. We have had member of the QA team to write patches (xml and sql) and check those in. This requires a build to make sure those get into the package. With this approach it really just took care of item 1 above and we fell apart on the other items. The nice thing is for the items that made it into the patches it was just an install with the utility.
b. A developer threw together a Config page on the application. All the configurations could be uploaded and downloaded via XML document but it requires the app to be running. For item 1, member of QA team would manually setup configurations in the application and then would download the Config.xml file. This XML file would be used to upload configurations in other environments. We would use text diff tool to look at differences between config.xml files from different environments. This addressed item 1 and the others items but had problems. Problems were not all configurations made it into the XML document (just needs to be fixed by developer), some of the configurations didn’t have a UI in the application so you still had to manually go to the database on some, comparing the XML document with text diff was difficult at time (looked mostly due to sorting but I’m sure there are other issues), XML was not very human readable and finally the XML document did not allow for deleting existing incorrect or outdated configs.
c. Recently we went with option B, but over time for a new client we just started manually tracking configs and promoting them manually by hand (UI and DB) through the promotions. Needless to say lots of human errors.
So we have been looking at solutions. Eventually it would be great to get as much automation in as possible. I’m looking at going with the scripting approach and just focusing on process, documentation and looking at using Redgate data compare in addition to what we had been doing with compare on config.xml. With Redgate we have to create views though and there is no way to create update scripts from that approach except to manually update the scripts. It does at least allow a comparison without the app running. I’m also looking at pulling out the configs from our normal patches and making it a system independent of the build (utility.exe –patch –config). When I say focus on process it will be things like if we compare and find a config change either reported by client or not, we still script it, just means we have to have a process in place to quickly revalidate config install before promoting to the next level. As for documentation looking at making the original QA document a living document instead of just an upfront document. The goal is to try and enhance clarity and reduce missing configurations during promotion. Unfortunately it doesn’t improve speed of delivery.
Does anyone have any recommendations or best practices to pass along. Thanks.
Can I ask exactly what you mean by application configuration. I'm interpreting that as both:
Config files in the web application
Static reference data inside the database
Full disclosure I work for Red Gate. You might be interested in taking a look at Deployment Manager, it's a deployment tool that deploys applications, databases and configuration. It's free for up to 5 projects and target servers.
The approach it uses is to package application code and the database state into packages. These packages can be deployed into dev, test, staging and production environments. The same package is deployed to each environment.
Any application configuration that needs to change between environments is handled in one of the ways below:
Variable substitution in web.config. The tool allows you to specify override values for variables in these files, and set these per environment/server
Substituting the web.config file per environment.
Custom powershell scripts that are run pre/post deploy. You could use these to execute custom SQL based on the environment or server.
Static data within the database, using SQL Source Control's static
data feature. I've written a blog post about how to supply
different sets of static data to different environments/customers.
This allows you to source control the application configurations and deploy them to different environments.
What is the best way to upgrade a local development version of DNN source without destroying the database (pages, settings, module settings, etc..)?
I'm currently moving from 07.00.XX to 07.02.00 and there is a tremendous amount of refactoring, seems impossible to just overlay the source.
Is there a way I can do this with preservation of all settings, etc....or will I need to rebuild parts of the site?
Since you are using the SOURCE package, you should be able to simply copy the SOURCE files from the ZIP file you download, over all of the existing files.
You might make sure that the new SOURCE package doesn't have a web.config file, if it does, remove/rename that so that it doesn't replace your existing web.config file, and thus saving your MachineKeys and connection strings.
Back up the FILES and Database before you attempt this however, just to be safe.
After the copy you might have to build the solution before the upgrade will work.
I typically don't recommend using the SOURCE package for DNN, unless you absolutely need to make changes (not recommended) to the source, it isn't necessary for doing Module Development or skinning.
I'm trying to divide my solution by three configurations:
Development
Testing
Release
All above will have different publishing location, so users can work with release, do their test in testing and see what is new in development release. All three versions will be build with different name postfixes and icons and installed on each user workstation.
For now I get :
Unable to install this application because an application with the
same identity is already installed. To install this application,
either modify the manifest version for this application or uninstall
the preexisting application."
I can't even install this more than once at one workstation.
So What can I do to achive this?
You can not install the same application multiple times unless you change the deployment. The easiest way to do this is by changing the assembly name. This article explains this.
As time past, I can now see that the solution was quite close, just required me to be able to specify my requirements first.
So, now I can tell that it mostly depends on number of such configurations:
if it is limited and low, i.e. live/test/dev, you can have each as separate project in solution, like AppLive, AppTest, AppDev, this requires refactoring to move everything that is common into separate projects, but it makes code and releases clearer and easier to manage.
if those configurations are unlimited, or number is high, than way to go is to load configurations from file and pick one from the pool based on custom logic.
Currently I'm using mix of both, as I want to be able to release test versions earlier than live, but also my application is used by multiple branches, and each of them has some unique styling, logos and such, so this is applied from embed xml file, and proper set is identified based on Active Directory entries.
I am running Sitecore 6.5
I have two installations of Sitecore and want to transfer a whole site from one installation to another.
Have found a few articles that go into Serialization and Creating a Package although they don't go into detail about how these two fit together.
How do I transfer a site from one installation to another?
thanks.
Create a package with the package designer.
include these items and their children with the button "items statically". if you have placed your solution specific item in folders, it is only needed to include these.
/sitecore/content
/sitecore/layout
/sitecore/media library
/sitecore/templates/ (only take the templates you have created. e.g. the folder user defined
using the button "files statically", include the folders with you have solution specific changes to like:
/bin
/layouts
/app.config/include (only take the files changed in the solution,
compared to a default sitecore installation)
web.config (if you have made changes to this, compared to default
sitecore web.config)
if you have any user accounts you want to transfer to, you can include them with "security accounts".
then generate zip file and install on empty sitecore and full publish :)
If your systems are similar enough, you may want to consider moving the Sitecore DBs via backup/restore (in SQL) and copying over filesystem assets. Generally I find this faster and less prone to user error than creating/installing very large packages. (Just remember to take back-ups first.)
Large packages have a tendency to break, one option would be to look into this:
http://www.hhogdev.com/Products/Team-Development-for-Sitecore/Overview.aspx
TDS can sync all your items to XML on your dev box and from that you can create a different sort of installation package which is significantly more robust than a regular package you create through the Sitecore desktop. It's the same sort of package that Sitecore use when you upgrade versions.
I believe there is a 60 day trial on this product so plenty of time to try it out.
Note: when transferring user accounts, passwords will not be migrated when using either packages or serialization.
Solution is here - cowboy-aspx from Sitecore :)
https://kb.sitecore.net/articles/242631