This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: ISLE 2015 not using correct library
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 23, 2015
12:55 AM
ISLE 2015 not using correct library
Hi,
We upgraded ISLE from 2013 to 2015 due to known problems with .Net 4.6 being installed on our development workstations. Everything seemed to be fine until we noticed that upgrades using generated msi files were not missing a library. Fresh installs and repairs worked fine. After digging through Orca, we found the issue to be with 2015 using an older version of the DLL.
The issue is with Microsoft.SharePoint.Client.DLL.
The DLL is set as Specific Version: false, Embed: false, Copy Local: True
The project references the dll directly from a directory with the correct library version to use.
Upon building the Installer, ISLE correctly identifies the dependency on the library and adds it, BUT it selects the GAC version not our "local copy". This is not how 2013 worked and is causing problems.
2013 correctly uses 15.0.4713.1000 from file system.
2015 incorrectly uses 15.0.4701.1000 from GAC
This causes the msi to remove the library during an upgrade and not add it back.
Can I have some explanation on why this behaviour has changed and how we can get it to work as per 2013 without sticking with 2013 minus .Net 4.6 or manually adding the library to the output?
Regards
We upgraded ISLE from 2013 to 2015 due to known problems with .Net 4.6 being installed on our development workstations. Everything seemed to be fine until we noticed that upgrades using generated msi files were not missing a library. Fresh installs and repairs worked fine. After digging through Orca, we found the issue to be with 2015 using an older version of the DLL.
The issue is with Microsoft.SharePoint.Client.DLL.
The DLL is set as Specific Version: false, Embed: false, Copy Local: True
The project references the dll directly from a directory with the correct library version to use.
Upon building the Installer, ISLE correctly identifies the dependency on the library and adds it, BUT it selects the GAC version not our "local copy". This is not how 2013 worked and is causing problems.
2013 correctly uses 15.0.4713.1000 from file system.
2015 incorrectly uses 15.0.4701.1000 from GAC
This causes the msi to remove the library during an upgrade and not add it back.
Can I have some explanation on why this behaviour has changed and how we can get it to work as per 2013 without sticking with 2013 minus .Net 4.6 or manually adding the library to the output?
Regards
(2) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 01, 2015
03:36 PM
Hi,
Are there any files with Scan at Build set to dependency?
Is it possible that the wrong file could be pulled in because of that?
Also, are there multiple of the same file in the built installer?
Are there any files with Scan at Build set to dependency?
Is it possible that the wrong file could be pulled in because of that?
Also, are there multiple of the same file in the built installer?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 17, 2015
09:05 PM
kyi wrote:
Hi,
Are there any files with Scan at Build set to dependency?
Is it possible that the wrong file could be pulled in because of that?
Also, are there multiple of the same file in the built installer?
I reverted back to an earlier version of ISLE which wasn't causing issues. Using the same setup file (edited to change version number to make it compatible) behaves differently between the versions.
I'd like not to have to manually add all my references if possible, but at the moment, it looks like it's the only way to be sure.