we have our business apps and size is 64 MB. every time add new functionality or change existing one then we rebuild our setup and deliver to client. so this means every time we are delivering 64 MB or more than that to our client.
we have our main win form project and also there many other class library project in our project solution. i am looking for easy way out to deliver only changes to our client.
may be changes could be there in our win form project or could be there in any class library.
so wherever changes made i just only deliver changes through setup and i want just client would install that setup or run any exe file and could see the changes we made in code.
i create setup with VS2005 setup creation option. how suggest me the best option for creating patch like apps which any client just install and get the changes in his apps. give me the best idea to implement in detail. thanks
When using Wix to generate an installer for your project, you can use it to also generate a patch file which will update only changed files.
Visual Studio 2005 setup projects don't really support Patch building and such. It's meant as a rudimentary solution for building installers. Wix, however, is what Microsoft uses internally to build the setup experience for Visual Studio 2012 and other products. There is a very extensive walk-through available here.
Wix does come with a steep learning curve. Would you have been using Visual Studio 2010 or 2012, then you could take advantage of a couple of templates that make it much easier to build a setup for a given type of application. I don't believe these will work with Visual Studio 2005.
This book might also guide you.
Related
Im having a hard time figuring out what the best approach is when designing my build process. It seems Microsoft have turned things around (again).
I am using TFS 2015 and Visual Studio 2015. For earlier versions of TFS I have normally created custom code activities that I plug in to my build definition process file (xaml). I like this approach because it gives me great flexibility and enables me to code .NET classes. I used these guides:
https://msdn.microsoft.com/en-us/library/dd647551(v=vs.120).aspx
http://www.ewaldhofman.nl/post/2010/04/29/Customize-Team-Build-2010-e28093-Part-4-Create-your-own-activity.aspx
In TFS 2015 it seems that there is no documentation on how to create custom code activities. In fact, it seems that Microsoft have changed things and now focuses on scripting languages in stead of custom .NET code: https://msdn.microsoft.com/en-us/Library/vs/alm/Build/steps/index.
I have created a custom code activity and it seems to be working in TFS 2015 (with a few hacks) so it is still possible, but I am nervous that this approach is no longer the way to go.
Can anyone provide information about what is happening here?
TFS 2015 introduces new builds, which are web- and script-based, and highly customizable. Meanwhile, TFS 2015 will continue to support the XAML Build templates and controllers.
The new builds are based on a different architecture and run on a completely different system. Currently, you can use both the new builds and agents alongside your XAML builds, controllers, and agents.
Which builds should I use?
If you are new to Team Foundation Server (TFS) and Visual Studio Team Services, you should use this new system. Most customers with experience using TFS and XAML builds will also get better outcomes by using the new system.
The new builds are web- and script-based, and highly customizable. They leave behind many of the problems and limitations of the XAML builds. For example, this new system embraces the diverse set of domain-specific languages (DSLs) that developers used to build the code on their dev machines. We expect this will reduce the chances of running into the "builds fine on my machine but not on the CI server" problem.
If you have heavily customized XAML builds and custom activities, you can continue using those builds until you are ready to port your business logic into scripts that can run in the new builds.
Useful articles for your reference:
https://blogs.msdn.microsoft.com/visualstudioalm/2015/02/12/build-futures/
https://msdn.microsoft.com/en-us/library/vs/alm/build/feature-overview
Our main website is a collection of 10 separate ASP.NET projects and applications. At the moment, to do a complete deployment onto a fresh server involves running ten separate msdeploy jobs; each application is built, configured (using config transforms) and packaged, but we don't have any solution for deploying all the packages as a single operation.
I can see several possibilities that might work in this scenario, but would love to hear from anybody who has succeeded - or failed - in setting up something similar:
A folder full of packages and deploy.cmd scripts, with a "master script" that will call each individual app script in turn and deploy that app to the target server.
Using a staging server where we deploy the latest build of each package from TeamCity using the production configuration, but then use msdeploy to capture that server into a single enormous msdeploy ZIP package, which is then deployed onto each production server as a single msdeploy step.
Creating a single, enormous Visual Studio solution that references EVERY project in our codebase (perhaps via svn:externals?), compiles and cross-references them ALL, and hence supports using a single msbuild job to create a huge monolithic package containing our entire codebase, built from the latest revision in source control and configured for the target environment.
I've studied Troy Hunt's excellent "You're Deploying it Wrong" series, and Scott Hanselman's "Web Deployment Made Awesome" article, but I think I'm looking for something a step beyond either of these approaches that incorporates multiple projects and applications without necessarily building them from source in a single step - any ideas?
We had a very similar scenario in our company, and we created an installation package using WIX. Our config transform happens at installation time, so now we create a single build, then deploy that to each server via an MSI install package. WIX is very flexible, but also has a steep learning curve. We modify our configs using our own custom action, but it could be done other ways.
We use Team Foundation Server and MSBuild to do our builds. This is pretty straight forward, but did take some work to set up correctly with as many projects and solutions as we had.
Other options we looked into, and even tried were:
InstallShield - Not flexible enough.
Writing our own C# Install - WIX already thought of everything we
were trying to accomplish so why reinvent the wheel?
Just saying to heck with it all and installing things manually - 2 or
3 months of development time in WIX and MSBuild have easily paid for
the hours we would have spent of the last year doing things manually.
I think the deployment tools built into Visual Studio were designed for a single application with just a few deployments. It sounds like you need external tools, and development effort, to get your deployments quicker, and eliminate the need for doing things manually. That's why we invested in the above solution, and it has really paid off.
I'll pick Installshield.
Installshield latest versions support creating webdeploy packages.
You can define the IIS configurations for all apps in a single project and create releases if you want to create packages by separate or one single release for all web apps.
Installshield project has an object model where you can automate basically every task from build scripts, also the projects are simple xml files that you can also modify in automation scripts if required
Developers can modify update WixXML projects by separate and you can add those projects builds as merge modules to your installshield projects through your build scripts with some little tweaks to the installshield project xml (at least in 2011 version, this part is not supported by installshield but can be done)
You don't even need to modify Visual Studio Projects for groups of web apps that follow a same pattern, neither manually modify your installshield project to add new web apps for these cases, you can create packages for new web apps without intervention setting one time your build scripts for the installshield project automation task based on the root VS build output
I'm developing a Windows service in VS2012 and the setup/deployment part has been removed. So I'm not able to create a setup project. I would like to hear what you guys could recommend for a good easy to use the installer. I need to take some inputs, only strings, under the installation of the service. I've been looking at WiX but that seems a bit complex, and I only got 1 or 2 days to make this installer.
So what installer should I use other than Wix?
I've had really bad experiences with InstallShield LE (the one that comes with Visual Studio 2012), especially for Windows Services. The features that you need to install a service (custom actions, etc), don't come with the light version.
What I'm planning to do for the current Windows service I'm working on is to build it with Topshelf, which (amongst other things) means installing your service is as simple as running MyServiceApp.exe install. I'm sure even InstallShield will let you run your app once it's installed, and then your app/Topshelf can install the service component.
If InstallShield doesn't work for you, I've had good results before with NSIS. Simple, powerful, free, decent documentation. It looks a bit clunky.
Here is a list of setup tools which can get you started:
http://en.wikipedia.org/wiki/List_of_installation_software
If you don't have a lot of time for creating the installer, I recommend using a commercial tool like Advanced Installer or InstallShield. You need a license, but they are focused on usability (do more in less time).
You can do it with InstallShield LE... You can add custom actions "After Register Product" for install and for "After System Changes". These custom actions can run an EXE on the machine.
Make sure you run the command line tools "in system context"
After Register Product run the version of InstallUtil to your version of .NET
eg.
path=C:\Windows\Microsoft.NET\Framework\v4.0.30319
command=InstallUtil.exe "C:\Program Files (x86)\XXX\YYY\ZZZ.exe"
replacing XXX YYY and ZZZ to match your install
After System Changes to delete your service name run
e.g.
sc delete "servicename"
Note you need support for the custom actions within your own service executable (you needed this in earlier VS too).
You can find more information about SC here:
http://support.microsoft.com/kb/251192
To add an installer for a service, you just need to right-click on the designer for the service and click "Add Installer".
Here's the walkthrough:
http://msdn.microsoft.com/en-us/library/zt39148a.aspx
I am creating a windows application setup project using Visual studio 2008 setup project. This setup will have following steps:
Splash screen
Select Installation folder/directory
Database configuration
Select Components
I am having trouble finding a way to create such installation window in setup. could you please help me to find a solution for this?
Visual Studio's routine for creating install/setup files is fairly weak compared to what you can find out there. Personally, I use a program called Inno Setup. It's an extremely powerful scripting program that allows you to completely customize the installation process. You may have to spend a little bit of time learning the basics of the scripting language it uses but will be well worth whatever time you may spend understanding the language to use the setup utility to create complete installation files for your current and future programs.
Generally when I use ClickOnce when I build a VB.NET program but it has a few downsides. I've never really used anything else, so I'm not sure
what my options are.
Downsides to ClickOnce:
Consists of multiple files - Seems easier to distribute one file than manageing a bunch of file and the downloader to download those files.
You have to build it again for CD installations (for when the end user dosn't have internet)
Program does not end up in Program Files - It ends up hidden away in some application catch folder, making it much harder to shortcut to.
Pros to ClickOnce:
It works. Magically. And it's built
into VisualStudio 2008 express.
Makes it easy to upgrade the
application.
Does Windows Installer do these things as well? I know it dosen't have any of the ClickOnce cons, but It would be nice to know if it also has the ClickOnce pros.
Update:
I ended up using Wix 2 (Wix 3 was available but at the time I did the project, no one had a competent tutorial). It was nice because it supported the three things I (eventually) needed. An optional start-up-with-windows shortcut, a start-up-when-the-installer-is-done option, and three paragraphs of text that my boss thinks will keep uses from clicking the wrong option.
Have you seen WiX yet?
http://wix.sourceforge.net/
It builds windows installers using an XML file and has additional libraries to use if you want to fancify your installers and the like. I'll admit the learning curve for me was medium-high in getting things started, but afterwards I was able to build a second installer without any hassles.
It will handle updates and other items if you so desire, and you can apply folder permissions and the like to the installers. It also gives you greater control on where exactly you want to install files and is compatible with all the standardized Windows folder conventions, so you can specify "PROGRAM_DATA" or something to that effect and the installer knows to put it in C:\Documents and Settings\All Users\Application Data or C:\ProgramData depending on if you're running XP or Vista.
The rumor is that Office 2007 and Visual Studio 2008 used WiX to create their installer, but I haven't been able to verify that anywhere. I do believe is is developed by some Microsoft folks on the inside.
I agree with Joseph, my experience with ClickOnce is its great for the vast majority of projects especially in a corporate environment where it makes build, publish and deployment easy. Implementing the "forced upgrade" to ensure users have the latest version when running is so much easier in ClickOnce, and a main reason for my usage of it.
Issues with ClickOnce: In a corporate environment it has issues with proxy servers and the workarounds are less than ideal. I've had to deploy a few apps in those cases from UNC paths...but you can't do that all the time. Its "sandbox" is great, until you want to find the executable or create a desktop shortcut.
Have not deployed out of 2008 yet so not sure if those issues still exist.
Creating an installer project, with a dependency on your EXE (which in turn depends on whatever it needs) is a fairly straightforward process - but you'll need at least VS Standard Edition for that.
Inside the installer project, you can create custom tasks and dialog steps that allow you to do anything you code up.
What's missing is the auto-upgrade and version-checking magic you get with ClickOnce. You can still build it in, it's just not automatic.
I don't believe there is any easy way to make a Windows Installer project have the ease or upgradability of ClickOnce. I use ClickOnce for all the internal .NET apps I develop (with the exception of Console Apps). I find that in an enterprise environment, the ease of deployment outweighs the lack of flexibility.
ClickOnce can be problematic if you have 3rd party components that need to be installed along with your product. You can skirt this to some extent by creating installers for the components however with ClickOnce deployment you have to create the logic to update said component installers.
I've in a previous life used Wise For Windows Installer to create installation packages. While creating upgrades with it were not automatic like ClickOnce is, they were more precise and less headache filled when it came to other components that needed to be registered/added.