Register | Log In
Download Contact
Community > Community Exchange

Welcome to the Community Exchange

Welcome to the Community Exchange, a place where community members can exchange questions and answers related to DotNetNuke. If you would like more info about the Community Exchange, please visit this page in our Wiki. 

Ask a Question

DLL Versioning Issues - Best Practices?

I have a production DNN PRO server running 6.01.  I've updated my development environment to 6.2.

I've just modified a custom module in my dev environment and pushed it up to production, but I'm getting the following error.

Error: is currently unavailable.DotNetNuke.Services.Exceptions.ModuleLoadException: (0): error CS1705: Assembly 'Coaxis.Modules.BulletinAdmin, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' uses 'Telerik.Web.UI, Version=2012.1.411.35, Culture=neutral, PublicKeyToken=121fae78165ba3d4' which has a higher version than referenced assembly 'Telerik.Web.UI, Version=2011.1.519.35, Culture=neutral, PublicKeyToken=121fae78165ba3d4' ---> 

I get what this is telling me - that the module was compiled using the newer Telerik DLL in 6.2 which doesn't match up the version of the DLL in the production server.

So, can I develop in a newer version, but deploy it to an older production version?  If so - how do I get around this issue?  I have the reference settings set to COPY LOCAL = FALSE and SPECIFIC VERSION = FALSE.  
asked 6/5/2012
Greg Griffin40
Greg Griffin

2 Answers

This answer has been selected by the question author as the best answer.

No, you cannot.  You can develop on the older version and deploy to a newer version, but you cannot deploy to an older version.

However, with your development environment, assuming you're using the Web Application Project model (rather than the Web Site Project model), you can reference the DNN 6.1 assembly, but run it on your 6.2 site (lower deployed to higher).
answered 6/5/2012 Brian Dukes 815
Brian Dukes
edited 6/5/2012
Brian Dukes815
Brian Dukes

  • We keep the DLLs in source control with the modules, so they can be compiled against the "correct" version without being in the context of a DNN site. - Brian Dukes 6/6/2012

  • So, do you maintain multiple full DNN installs in your local dev environment? Or just keep the old DLL's handy so that they can be referenced.

    Our custom modules are for internal use and thus we are only trying to support the latest version of DNN at any given time. Maintaining multiple full installs seems like overkill for our needs. - Greg Griffin 6/5/2012
Daily sweepstakes at I Love Giveaways
answered 6/6/2012 sweepsguy1 2
sweepsguy1

Your Answer

In order to provide an answer to this question, you must Login

I am flagging this question because...
10 inform moderator flags remaining

I am deleting this question because...

I am flagging this answer because...
10 inform moderator flags remaining

Flagging a Post

You have already flagged this post. Clicking "Remove Flag" below will remove your flag, thus reducing the count by one as well.

I am deleting this answer because...

DotNetNuke Corporation

DotNetNuke (DNN) provides a suite of solutions that make designing, building and managing feature-rich sites and communities fast, easy and cost-effective. The DotNetNuke Platform CMS is the foundation for more than one million websites worldwide. DNN Social, our newest solution, enables businesses to create immersive, interactive communities. Thousands of organizations like True Value Hardware, Bose, Cornell University, Glacier Water, Dannon, Delphi, USAA, NASCAR, Northern Health and the City of Denver have leveraged DNN to deploy highly engaging business- critical websites. Our rapid growth in product sales and deployments resulted in DotNetNuke Corp. being named one of the fastest growing private companies in America by Inc. Magazine in 2011 and 2012.
Copyright © 2002-2013 DotNetNuke Corp. / Terms of Use / Privacy
Hosted by MaximumASP