I have three different MSI's created to deploy my project. My end result is to run a single exe that will call the rest three MSI's, with the current running installation description or name. As same as we see while Visual Studio Installation.
I have tried WIX but didn't come up with anything. Please guide.
Environment - Visual Studio 2008 / 2010 with Win 7
You're looking for a bootstrapper (sometimes called a chainer). There are many available, including open-source ones like DotNetInstaller and WiX's Burn.
You could create one MSI and combine all you project's primary outputs. If you need to separate them just add a folder for each project's primary outputs.
Related
I've created an Outlook add-in, debugged and works fine. I want to be able to package it up for distribution. This is for a very limited audience 5-10 people. What are the steps to doing so?
I tried Build | Publish which appears to work (using options of local filename and CDROM install location), but creates a massive 1.5MB setup.exe file and when it is executed, takes forever (it appears trying to contact some remote server and times out and pops an error, although the add-in appears to be registered).
Looking online, I found references to creating a SetupProject or using InstallShield Limited addition, but none of those appear to apply to Visual Studio 2017.
I'd be happy if I could just provide my DLL and a .reg file -- this is for a small set of 5-10 power users.
What is the simplest way to deploy this add-in?
The easiest way is Build | Publish. Just disable any online activities if you don't want it. You can do that in Project -> Settings -> Publish. Check your "Updates" settings for example.
You can download a Visual Studio project type from here:
https://marketplace.visualstudio.com/items?itemName=VisualStudioProductTeam.MicrosoftVisualStudio2017InstallerProjects
This will allow you to deploy the package, but it's somewhat buggy in my opinion. Also, the link above does not have any documentation. You have to go to another page for that and the answer is buried in the comments:
https://msdn.microsoft.com/en-us/library/ybshs20f(v=vs.90).aspx
The ClickOnce has worked more consistently for us, however. Just right-click and select Publish on the Project.
It is a long ways off from the old InstallShield LE process, which allowed you to customize the entire process including images, click-through licensing, etc.
But the InstallShield LE had it's own set of issues, and seems to have been all but abandoned.
It may be worth looking at other 3rd-party tools like WiX (http://wixtoolset.org/) to get things installed correctly, or even manually writing your own installer to get things put where they need to be.
Having trouble getting MSBuild/Visual Studio 2012 to deploy a CRM 2011 Plugin Assembly to a named CRM Solution.
I've 2 project/SLNs. In one, I can precisely control which CRM Solution the build deploys a Plugin Assembly into; my msbuild (call this build-1) creates a CRM Solution with my custom entities/forms and Plugins. In another, despite specifying the exact values via msbuild /p for CRMOrganization, CRMSolutionName, CRMDiscoveryServer, 'CRMDiscoveryServerScheme, the resulting CRM Solution contains only the entities/forms. The Plugins are deployed but placed incorrectly into the Default Solution (call this build-2).
I've created build-2 from copy/pasting the values (except SLN and Project names) from build-1...and am at a loss to understand why build-1 deploys the plugins to my named CRM Solution, but build-2 deploys them to the Organization's Default CRM Solution.
Any ideas?
CRM might look specifically at Display name instead of Schema Name as the solution Name.
Unfortunately the CRM Developer Toolkit in both VS010 and VS2012 versions is configured at the solution level only. Therefore, despite adding multiple projects to your solution they will both use the CRM Organisation settings at the solution level. It's a rather annoying limitation that's existed since the first release of the tooling I'm afraid.
The MSBuild target file used by VS (Microsoft.CrmDeveloperTools.CrmClient.target) is available at the default install location C:\Program Files (x86)\MSBuild\Microsoft\CRM. This folder also includes the supporting assembly containing the MSBuild Tasks if you felt like rolling your own build target.
I've looked at this briefly myself in the past but a word of warning, many of the classes in that assembly are sealed so extending them is off the table.
I have developed an Excel XLL using ExcelDNA and C#. I am at the point where I would like to begin testing the deployment, but cannot find much information that actually provides steps that work.
My project was developed as a Class library with ExcelDna references. In the .dna file, I have the code below that will pack all resources into a packed version of the XLL (i.e. the Pack="true" attribute).
<DnaLibrary Name="ExcelXLL" RuntimeVersion="v4.0" Language="C#">
<ExternalLibrary Path="ExcelXLL.dll" LoadFromBytes="false" Pack="true" />
I would like to deploy the packed XLL to the target machine in the path:
%APPDATA%\Microsoft\AddIns
In order to automatically register the XLL with Excel, I need to add a registry key that depends on the version of Excel that the user has.
For instance, on my computer (Windows 7 64 bit running Excel 2007 32-bit), I would need to add a registry key to the following path:
HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Excel\Options\
The key would be type REG_SZ with the name OPEN (or OPEN1, OPEN2, etc.) and the value
/R "ExcelXLL-packed.xll"
I have 2 problems though. The first is in determining which version of Excel that the user has to get the correct path and the 2nd is to determine the correct OPEN version that I need to create (for example, if the user already has OPEN, OPEN1, and OPEN2 then I would create an OPEN3 key).
I am trying to do the installation using either the Setup and Deployment project or a InstallShield LE project and cannot determine how to go about this. Does anyone know how to do this or a better way of doing it?
EDIT 1:
I have done a great deal of research on this and have looked at several windows installers.
In the Package and Deployment and InstallShield LE, I can get the install/uninstall to work by putting an installer class into my class library and bundling project output with the install. In this approach, I handle inserting/removing the registry key using the installer class. The problem that I have is that the user must uninstall first before running a new install (no update capability).
I downloaded the Setup Factory demo version and can get install/update to work but cannot do the framework check (not shipped with the demo). Also, the uninstall fails (though I may be able to get this to work with some more investigation).
I am interested in using the WiX installer, but would like to know if anyone has a sample of how to perform the deployment using WiX. I would also like to know if I need to use the installer class or if there is a different way to handle the search for the OPEN[n] key under HKCU\Software\Microsoft\Office[Version].0\Excel\Options. If I were to use the project output to enable the installer class, then I need to have 2 separate target directories (one under Program Files for the basic project output and one under %appdata%\Microsoft\AddIns for the packed XLL).
Any help is greatly appreciated.
Thanks,
Lee
To detect Excel 32-bit vs. 64-bit, you can check the registry: Detect whether Office is 32bit or 64bit via the registry
For the OPEN, OPEN1, OPEN2 etc. you typically need a Custom Action in the install script that enumerates the keys.
Using IsWix and Wix 3.7, I was able to resolve this.
Useful links for how to register the components are as follows:
For generating a C# class to handle Windows Installer Custom Actions:
http://www.codeproject.com/Articles/132918/Creating-Custom-Action-for-WIX-Written-in-Managed?fid=1599130&df=90&mpp=25&noise=3&prof=False&sort=Position&view=Quick&spc=Relaxed&select=4131367&fr=1#xx0xx
http://blogs.msdn.com/b/jschaffe/archive/2012/10/23/creating-wix-custom-actions-in-c-and-passing-parameters.aspx
For setting the property of the CustomAction.config file to Content
WIX Custom Actions built for .Net Framework 4.0 does not work? Ways to resolve?
EDIT 1:
For general knowledge on WiX (Very important)
http://channel9.msdn.com/blogs/scobleizer/wix-team-the-most-used-piece-of-software-at-microsoft-and-its-open-source#Page=2
I've seen similar questions and answers but found them not really what I want.
I have a large solution with several web projects in it. All the web projects share some common code so they are all part of the same solution (there is a common project that is referenced by all of them).
I've been running on Team Foundation Server 2008 and we are upgrading to TFS 2010 to be ready for our move to visual studio 2010 and .net 4.0.
I've got the build working with a 2010 build by creating a new build because we only had one customization I'm trying to reproduce.
Once the build is done I have the files dumped at
\\SERVER\tfsdump\devel2010 build\devel2010 build_20101008.3\_PublishedWebsites
by using the dump folder option but the build location is
C:\Builds\1\Web Applications\devel2010 build\Binaries\_PublishedWebsites
All I want to do is after the build is finished I want to copy _PublishedWebsites\SiteA to \ServerA\ShareA
and copy _PublishedWebsites\SiteB to \ServerB\ShareB
Because there is only one build agent all I need is to call a batch file to run the copy but for easy of use for my developers I need this batch file to be called after every build. Is this possible or is there a better solution?
To make things harder the site is still a 2008 project and it is requested that it stays that way until we can fully test it under VS 2010.
Use a CopyDirectory build activity, set Source property equal to BuildDetail.DropLocation + "\_PublishedWebsites\SiteA" and set Destination property to your desired location. I have put this activity as the last activity in build process and it works properly.
Taking a cue from Afshar's answer, for people directly editing XAML template file, create a new sequence after copy to the Drop location is successful:
DisplayName="Something" Source="[BuildDetail.DropLocation + "_PublishedWebsites\SiteA " ]" />
The quotes inside should be written as " and semicolon.
Running any of the Crystal Reports 10.5 redistributables (CRRedist2008_x86.msi, CRRedist2008_x64.msi or CRRedist2008_ia64.ms) is supposed to, according to the Crystal_Runtime2008.txt file, deploy the following files:
CRVsPackageLib.dll
CrystalDecisions.CrystalReports.Design.dll
CrystalDecisions.CrystalReports.Engine.dll
CrystalDecisions.Data.AdoDotNetInterop.dll
CrystalDecisions.Enterprise.Desktop.Report.dll
CrystalDecisions.Enterprise.Framework.dll
CrystalDecisions.Enterprise.InfoStore.dll
CrystalDecisions.Enterprise.PluginManager.dll
CrystalDecisions.Enterprise.Viewing.ReportSource.dll
CrystalDecisions.Keycode.dll
CrystalDecisions.ReportAppServer.ClientDoc.dll
CrystalDecisions.ReportAppServer.CommLayer.dll
CrystalDecisions.ReportAppServer.CommonControls.dll
CrystalDecisions.ReportAppServer.CommonObjectModel.dll
CrystalDecisions.ReportAppServer.Controllers.dll
CrystalDecisions.ReportAppServer.DataDefModel.dll
CrystalDecisions.ReportAppServer.DataSetConversion.dll
CrystalDecisions.ReportAppServer.ObjectFactory.dll
CrystalDecisions.ReportAppServer.ReportDefModel.dll
CrystalDecisions.ReportAppServer.XmlSerialize.dll
CrystalDecisions.ReportSource.dll
CrystalDecisions.Shared.dll
CrystalDecisions.Web.dll
CrystalDecisions.Windows.Forms.dll
But I am unable to find these anywhere on the PC. Does anyone know what location they're installed to? All the other DLLs listed in the .txt file appear in
c:\Program Files\Business Objects\Common\2.8\bin
the GAC
Starting with the .NET Framework 4, the default location for the
global assembly cache is %windir%\Microsoft.NET\assembly. In earlier
versions of the .NET Framework, the default location is
%windir%\assembly
Use Process Explorer on a running version of the app, such as your dev machine, to see from where all of its DLLs are loaded.
EDIT:
Process Explorer is a great way to find out what DLLs are loaded into any Windows process be it from the GAC or any other location. This method (using ProcEx) is general, but IMO useful in many scenarios. ProcEx would indeed show you that a program's Crystal Redist was being loaded from the GAC.
SUGGESTED EDIT:
Find .NET DLLs in this way:
Find your task in the process list of Process Explorer
Double click on the task to show Task Properties
At .NET Assemblies tab open plus(+) sign, display App Domain etc. (only .NET processes will have this tab. Non.NET process will not have the tab at all)