Reducing version dependencies?

So I've got these iParts, see?  They have references to several ASI dlls, typically Asi, Asi.Business.ContentManagement, Asi.iBO, Asi.Web, Secure and Telerik.Web.UI.  I have those files in my project folder, it builds my dlls just fine and works great...until the client upgrades.  At that point, my code refuses to run because it can't find the file it was compiled against.  Telerik is the most common offender.  Moving from 15.1.1 to 15.1.2 required a new dll even though I was using only features available in both flavors.

I'm trying to avoid compiling and distributing new copies of each of my iParts for every release and patch of iMIS.  That's a lot of installers to maintain.  Keeping another copy of the same file, perhaps in the GAC, seems messy and probably not the right approach.

I've done a bit of research on MSDN and StackOverflow about manifests, especially the dependentAssembly > bindingRedirect attributes.  From what I've learned so far, I think I could distribute a new manifest whenever non-breaking changes are made to my dependencies.  Has anyone tried this and got it to work?  (This also looks like something ASI may be able to fix more globally by incorporating such changes into web.config for everyone's benefit.)

I realize that if the dependency has important changes in behavior, then bindingRedirect is going to move the problem instead of solve it.  At that point, a new version of my iPart makes sense, as I probably have to modify my code as well.

Does anybody have any other suggestions for how to solve this?

Is there something ASI could do differently with their DLLs to make sure I'd only have to build an installer for each _major_ version of iMIS instead of each patch?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Hi I found nice article

Hi

I found nice article related version dependecies,

http://blog.fredrikhaglund.se/blog/2008/02/23/get-control-over-your-assembly-dependencies/

basically by editing csproj file and remove version number other details and compile so your dll is not related to any version numbers

For example by default your reference created like this 

    <Reference Include="Asi, Version=15.1.2.5901, Culture=neutral, processorArchitecture=MSIL" />
    <Reference Include="Asi.Business.ContentManagement, Version=15.1.2.5901, Culture=neutral, processorArchitecture=MSIL" />
    <Reference Include="Asi.ContentManagerNet, Version=15.1.2.5901, Culture=neutral, processorArchitecture=MSIL" />
    <Reference Include="Asi.iBO, Version=15.1.2.5901, Culture=neutral, processorArchitecture=MSIL" />
    <Reference Include="Secure, Version=15.1.2.4260, Culture=neutral, processorArchitecture=MSIL" />
    <Reference Include="System" />
    <Reference Include="System.Data" />
    <Reference Include="System.Core">

now you can change this section to something like this would solve the problem.

    <Reference Include="Asi" />
    <Reference Include="Asi.Business.ContentManagement" />
    <Reference Include="Asi.ContentManagerNet" />
    <Reference Include="Asi.iBO" />

I have not tested this but this should work.

Thanks

 

 

Hi I found nice article

Hi

I found nice article related version dependecies,

http://blog.fredrikhaglund.se/blog/2008/02/23/get-control-over-your-assembly-dependencies/

basically by editing csproj file and remove version number other details and compile so your dll is not related to any version numbers

For example by default your reference created like this 

    <Reference Include="Asi, Version=15.1.2.5901, Culture=neutral, processorArchitecture=MSIL" />
    <Reference Include="Asi.Business.ContentManagement, Version=15.1.2.5901, Culture=neutral, processorArchitecture=MSIL" />
    <Reference Include="Asi.ContentManagerNet, Version=15.1.2.5901, Culture=neutral, processorArchitecture=MSIL" />
    <Reference Include="Asi.iBO, Version=15.1.2.5901, Culture=neutral, processorArchitecture=MSIL" />
    <Reference Include="Secure, Version=15.1.2.4260, Culture=neutral, processorArchitecture=MSIL" />
    <Reference Include="System" />
    <Reference Include="System.Data" />
    <Reference Include="System.Core">

now you can change this section to something like this would solve the problem.

    <Reference Include="Asi" />
    <Reference Include="Asi.Business.ContentManagement" />
    <Reference Include="Asi.ContentManagerNet" />
    <Reference Include="Asi.iBO" />

I have not tested this but this should work.

Thanks

 

 

Tried it, doesn't work

I tried that.  That allows the project to ignore version numbers during compilation, but whatever version was present during the compile is what the dll will expect to find at runtime.

Thanks for the quick response and the idea.
--
Bruce Wilson
Director, Technical Services
RSM McGladrey, Inc.

You say you run into this

You say you run into this version dependencies with some of the ASI dlls as well?  Telerik versioning gives us issues at ASI too; we always have to build everything to test out a new version of Telerik controls.  And unfortunately for you, 15.1.3 will have a new version of Telerik controls yet again.

I worked on a project to try and strong name all of the Asi assemblies a couple of years ago ran into identical issues when trying to deserialize an object that was serialized using a different version of an assembly.  After a month and a half of working with them bindingRedirect was the only option they could come up with.  (And this is not feasible when we have assembly versions that change with every build we kick-off, thus we never were able to strong name our assemblies.)

So unfortunately, I don't know of a solution for you other than to add the necessary bindingRedirect statements in your web.config.  ASI has not had a need to use bindingRedirects yet, so I don't see anything like it being added to the web.config for an out-of-the-box install.  For now, it looks like it will be a manual step for you to add them as needed when you install you iParts on a system.

Good luck and let us know if you find another creative solution :)

Courtney Robertson

Isn't there a way to specify

Isn't there a way to specify "SpecificVersion=false" in the properties describing the references?  Or does that only ignore the Build Number portion of the version identifier?

SpecificVersion=false

The setting you're referring to shows up in the csproj like this:

    <Reference Include="Asi, Version=15.1.2.5454, Culture=neutral, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\ASIDepends\Asi.dll</HintPath>
    </Reference>

That's basically the same thing Balaji mentioned -- it only applies to build-time checks.  Once compiled, it expects to find a DLL that matches exactly.  (As I understand it the "15.1.2.5454" in the string is just a memo of the file used at compile time and doesn't imply a specific version unless SpecificVersion=True, so removing either one disables the build-time check.)

Based on what Courtney said, it sounds like "matches exactly" is a stricter test with strong-named assemblies than those that are not.  I read something about this somewhere.  I think the "name" basically becomes "MyLibrary{GUID}" with {GUID} changing with every build.  Without strong names, any "MyLibrary" which provides the needed methods with the right parameters will fit the bill.  I think.  I hope.

--
Bruce Wilson
Director, Technical Services
RSM McGladrey, Inc.