I have an app that uses a VS 2015 installer project.
Our BONEHEAD vendor, ComponentOne, released a new version of several assemblies upon which my product depends.
Here's the rub:
Old DLL version: 4.1.20102...
New DLL Version: 4.0.20162...
The newer DLL at least have newer file dates than the older one.
Of course, the newer DLL fix real user problems brought about by the bugs in the C1 components since corrected.
While I can get to the correct DLL by having the end user fully uninstall the older version of my product and installing the newer version, this is unworkable because:
We have an auto-update function that phones home and checks for the latest patch and installs it to update prevoius version; and
Our customers are female, 60+ and cyberphobic.
The project already has the RemovePreviousVersions property set to true, and I was hoping that this did a complete uninstall silently. It does not; the six assemblies with the version error are not replaced. The DetectNewerInstalledVersion property is also set to true; I tried to install with False, and it has no effect.
I also tried to explicitly include all detected dependencies of the C1 assemblies and it has no effect.
Is there a way to force the install project to overwrite the assemblies as long as the file date is newer regardless of the wrongly-encoded version?
Edited to add the following:
I tried making a custom action to delete the offending assemblies before installing anything - it runs after the files are installed. :(
I tried InstallShield LE, only to find out that it could not discover the dependencies more than one level deep, and provided no convenient way to explicitly specify the dependencies. I also could find nothing that would let me say to overwrite the assemblies based on date or unconditionally.
Thanks for any help you can offer!
I found an effective workaround.
I already had RemovePreviousVersions set to true, so I changed the application's default folder by adding [ProductVersion] onto the end of the path.
What this accomplished was:
It deleted the old assemblies; and
It created the new assemblies in the new folder.
This solved the problem nicely. No setting REINSTALLMODE to amus; no brute force solutions.
Related
Building MSIs with WixSharp since years, I always followed this rule which basically says:
For each new release of your application, change the ProductCode but never change the UpgradeCode.
This always worked perfectly but recently I discovered that installing a newer release of my application does not replace the previous version but instead is getting installed in parallel.
Running this PowerShell script gives me this result on a test machine:
My question
What is the reason that a MSI file does not replace an existing one upon installation with the same UpgradeCode?
(I've also posted this as a question on the WixSharp GitHub repository)
Update/solution
I've finally managed to solve it. Basically I did the following things:
Removed the version string from my setups name (since MSI seems to also compare then names to check whether an upgrade is possible; only the same name seems to fit)
Changed my version number from 4 to 3 digits, as Christopher pointed out. I.e. I'm now incrementing e.g. "1.0.0" to "1.0.1" etc.
Added this code to my WixSharp ManagedProject instance:
InstallScope = InstallScope.perMachine,
MajorUpgradeStrategy = new MajorUpgradeStrategy
{
UpgradeVersions = VersionRange.OlderThanThis,
PreventDowngradingVersions = VersionRange.NewerThanThis,
NewerProductInstalledErrorMessage = "Newer version already installed.",
RemoveExistingProductAfter = Step.InstallInitialize
},
After these changes, an upgrade succeeded.
The constraint is ProductCode not UpgradeCode. Only 1 MSI per ProductCode can be installed. Attempting to do so again will be a maintenance operation, small update or minor update.
Many MSI can share an UpgradeCode. (Not a good practice though!) For example it's not required for you to author a Major Upgrade at all.
The usual cause here though is you must change the version number in the first three fields and each install must be in the same context (per-user and per-user or per-machine and per-machine). BTW that's another way to install the same ProductCode twice. One per-user and one per-machine. Again not a good practice.
Good:
1.0.0 → 1.0.1 FindRelated Products in the 1.0.1 MSI will see the 1.0.0 and tell RemoveExistingProducts to remove it.
1.0.0 → 1.0.0 or
1.0.0.0 → 1.0.0.1 Bad. FindRelated will see it as the same version and not remove it.
I have no experience in patching/upgrading an installation.
We have a wix bundle setup with a standard (wix-created) msi inside which is added to the bundle this way:
<MsiPackage SourceFile="MySetup.msi" Id="MySetupId" Cache="yes" DisplayInternalUI="no" SuppressSignatureVerification ="yes" Visible="no" >
so in Add/Remove software section there is the bundle shown, not the msi itself.
Both, the msi and the bundle, are signed.
Currently our released version is "2.1.0.BuildNumber".
The bundle.wxs has upgrade code A
The msi has product code B and upgrade code C.
Unfortunately this version contains a mean bug but we don't want to release "v2.2.0.BuildNumber" just because of this bug, but "2.1.1.BuildNumber", so we need a patch.
What is be best practise here? Should we just create a msp file described like here
http://wixtoolset.org/documentation/manual/v3/patching/wix_patching.html?
Will this break the relationship between the bundle and the msi? Will this patch be shown in Add/Remove programms section?
Or is there a possibility to use the bundle for a patch?
Goal is, that our customers just can install the patch without deinstalling the old version, but can deinstall the whole scope using the formerly released bundle.
My personal advice is do not create patches unless absolutely necessary. You avoid a lot of trouble. The main problem IMO is that patches do not fit well onto source control and CI. First, you are not able to automatically increase the build number and include it into version number - it must remain the same. Second, creating an msp patch requires the binaries from the previous build be present during the new build. In MS technology the previous msi should be present, in WiX technology you cited you will need *.wixpdb from the previous build. Third (or the first?), the patch is a one-time action which should not be automated for continuous execution by CI.
If the bundle does not include its packages into exe but download them, a new bundle version can download only changed packages so that installation time will be small. Otherwise you are out of luck.
You need to create an msp upgrade for your buggy msi. The upgrade may or may not change the msi version, but if it does then the version of msi will not match the version of the bundle. User does not see msi version anyway.
You can install msp directly. When the bundle is uninstalled, msp will be uninstalled too. I do not know whether the msp will be visible in ARP (msi is not visible).
You may create a patch bundle. This is an independent bundle with its own upgrade code. It will contain
<Bundle .... ParentName="Name of your main bundle"...>
<RelatedBundle Id="YourMainBundleUpgradeCode" Action="Patch" />
Include MspPackage with your msp into the Chain.
This bundle will be visible in Installed Updates as a child of "Name of your main bundle" and it will be uninstalled with the main bundle or when a new version of the main bundle is installed.
You will also need to include a Condition to prevent installation of patch bundle when the main bundle of this particular version is not installed. There is no documented API to detect bundles (although you may use a RegistrySearch), but you may do ProductSearch for particular version of your msi included in main bundle.
Note that a new release of the main bundle with the same version number will install in parallel (there will be two identical entries in ARP) and new release with greater version number will automatically uninstall previous release. Thus, you cannot make new release of the main bundle.
Running a new site on Sitecore 8.1 - installed and setup Glass.Mapper but I cannot use calls such as #RenderImage - it's complaining that i'm missing the reference to Glass.Mapper.Sc.Mvc, which I have already.
The following are the Nuget modules installed for Glass.Mapper:
BoC.Glass.Mapper
BoC.Glass.Mapper.Sc
BoC.Glass.Mapper.Sc.CastleWindsor
Castle Windsor
Castle.Core
Glass.Mapper.Sc
I have it installed on another instance of Sitecore (7.5) - an older version of Glass.Mapper, but I've noticed that the Nuget packages do not exist anymore.
Any ideas?
Thanks!
Dan
BoC.Glass.Mapper is a fork of Glass Mapper, and I believe it has not been updated to V4. Remove it (and any configs that it added or deployed) and start again I say. Just add the Glass.Mapper.Sc nuget package will add in the correct dependencies and is compatible with Sitecore 8.1.
Just to be doubly sure, this is the correct version: https://www.nuget.org/packages/Glass.Mapper.Sc/
Make sure you have Sitecore.Kernel and System.Web.Mvc referenced in your project since there is a post-install step in the nuget package that adds the correct versions of Glass dlls to your project.
To make things simpler V4 uses a Powershell script to decided which
references to add to your project, it checks both the Sitecore.Kernel
version and the System.Web.Mvc version and then installs the
appropriate Glass.Mapper.Sc and Glass.Mapper.Sc.Mvc assembly.
With regards to #RenderImage, either inherit your view from GlassView<> or better to use the extension methods, e.g. #Html.Glass().RenderImage().
More info here: http://glass.lu/Blog/GlassV4
I'm trying to use the latest Exchange Web Services DLL, however when I search my hard drive I see many versions of Microsoft.Exchange.WebServices.DLL, the most recent being version 14.0.650.7 with a date of 1/24/12.
I want to rebuild my machine but can't find an official place to get this DLL. I attempted to download the latest SDK I don't see any DLL to use, nor is there any CHM for me to use.
Where can I get the latest version of Microsoft.Exchange.WebServices.DLL?
Current version of the EWS Managed API is 1.2. It seems that Microsoft sometimes forgets to update links to the newest download which makes it hard to find out what the newest version is but I usually go to www.microsoft.com/downloads and search for "Exchange Web Services Managed API" whenever I need a fresh download.
UPDATE:
EWS is on NuGet:
http://www.nuget.org/packages?q=EWS
This is an old question, and the two answers by the OP and #JakobChristensen do answer the question. I'll just mention that I'm finding the situation fairly confusing.
I recently (manually, not via NuGet) downloaded the current NuGet version, which they currently call "2.2.0".
https://www.nuget.org/packages/Microsoft.Exchange.WebServices/
But the internal file/product version on the .dll is 15.00.0913.015.
According to this page
https://msdn.microsoft.com/en-us/library/office/dn528373(v=exchg.150).aspx
the file should be placed here:
C:\Program Files\Microsoft\Exchange\Web Services\2.0\
So that's where I placed it. Later, when playing around with a Microsoft sample program I noted that it did indeed reference the file at that location.
But another Microsoft sample program referenced the file in the GAC!
C:\WINDOWS\assembly\GAC_MSIL\Microsoft.Exchange.WebServices\15.0.0.0__31bf3856ad364e35\Microsoft.Exchange.WebServices.dll
This version had file/product version 15.00.0847.030.
I'm not sure how that file got there, probably part of a Visual Studio installation.
There's also something called EWSCore, which is apparently a forked version of the official EWS with some bug fixes.
https://www.nuget.org/packages/EWSCore/
My current decision is that I'll consider the official NuGet version to be the version I'll standardize on, and manually download it to my development PC and my build PC and place it here:
C:\Program Files\Microsoft\Exchange\Web Services\2.0\
Options
If you use .net framework, there is a nuget package "Microsoft.Exchange.WebServices 2.2.0" here https://www.nuget.org/packages/Microsoft.Exchange.WebServices
If you use .netstandard/.net5+, you need to go the Github open source project "OfficeDev /
ews-managed-api" here https://github.com/OfficeDev/ews-managed-api , and there you download the code, and compile it. However, this project is targeting .net3.5. So, you need to convert/upgrade it to .netstandard/.net5+ manually and compile it for your self.
!! Update !!: I took the version as of date of this post from GitHub. Replaced Old Style project with SDK project. Target framework set to netstandard2.0. Added packages System.DirectoryServicesandSystem.Security.Cryptography.Xml. In files, I had to remove few namespaces that not compatible, but were not used. Removed AsImageinPhoto, this is public image retrieving method, not needed - it only converts byte array. And fixed loading issue with Assembly.GetExecutingAssembly().GetTypes();`
Type[] types;
try
{
types = Assembly.GetExecutingAssembly().GetTypes();
}
catch (ReflectionTypeLoadException ex)
{
types = ex.Types.Where(t => t != null).ToArray();
}
I also deleted or excluded from project bunch of files related to documentation, fxcop, and assembly info.
And then it worked for sending emails with different API versions. Reading emails is not tested yet.
There is a third option. Nuget has a package "Microsoft.Exchange.WebServices.NETStandard 2.0.0-beta3" But this is not an official Microsoft code. https://www.nuget.org/packages/Microsoft.Exchange.WebServices.NETStandard/2.0.0-beta3
!! Update !!: Got this version and compared to the original code in option #2. This code has more changes than necessary to convert to .netstandard. It has some async stuff added.
Is there a way to make visual studio not care about dll versions? Is this a bad idea?
I am resetting up my dev machine and I just installed the latest version of Pex and Moles (version .92). All my projects are on version .91.
We are in the middle of a release and don't want to upgrade right now. Also, I cannot find an installer to version .91.
When I try to compile I get a message that I am missing the reference. (Hence this question)
The version is important.. By definition, there is a difference from each released version to the next (or there would be no need for a new version). Your program may not perform correctly if you are expecting one version and instead have another.
This was a part of what was known as "DLL Hell" in the pre-.NET days... If you needed to use a third party component (Crystal Reports Viewer is one we always had to deal with), you would just use the reference to whatever installed version was on the user's PC. Our retail locations had to have a specific version of Crystal Reports for their bookwork reports to print correctly, and because of that, we had to hold on to an old version forever.. Upgrading Crystal on the PC broke the vendor's bookwork app. On my first ever PC, I had several applications break when I would install or upgrade another. In particular, Real Player broke my telephone answering machine software. Goofy stuff like that...
So, the version IS important, even if it is an annoyance. It's also why I have a bias against third party tools that I have no code for, and can't recompile myself.
If you look at the properties of a referenced DLL, you will see a property "Specific Version". If you set it false, it doesn't track the specific version in the project file.
For this to work, you have to somehow fix the references where ever they are used. You can do this by opening every solution and fixing the references (at which time you could also just update the references to the correct version, paying heed to David's comments).
If you have a lot of solutions, you might use a tool like sed (see this post for windows versions of tool like this Is there any sed like utility for cmd.exe) to just update the project files as needed all at once.