.dll Reference Error After Upgrading from VS2008 to VS2010

Dec 17, 2012 at 5:03 PM

We have a .NET project which is based on ASP.net 2.0 and is using "Yahoo.Yui.Compressor.dll" version 1.4.1.0.  After allowing Visual Studio to upgrade our project from 2008 to 2010, we immediately see a problem with the reference to the Compressor .dll.

"Type type of namespace name 'Yahoo' could not be found (are you missing a using directive or an assembly reference?)"

We also see a warning that the .dll has a dependence on the .NET 3.5 framework.  If we remove the reference and then add it back, we get the following dialog warning:

'Yahoo.Yui.Compressor.dll', or one of its dependencies, requires a later version of the .NET Framework than the one specified in this project.  You can change the .NET Framework target....."

Currently, we are not able to upgrade the .NET framework so we're stuck using 2.0.  But I'm confused as to why the .dll which worked when targetting 2.0 in VS2008 now fails when targetting 2.0 in VS2010.

Any suggestions?

 

 

 

 

Coordinator
Dec 17, 2012 at 5:14 PM

Suggest you update to the very latest YUI Compressor.  Although this is a breaking change, there is some extra goodness in there and some bug fixes.

Also where before there was separate 2.0 and 3.5 projects & assemblies, now there is only one, which targets .NET 2.0

Look at the docs on the site to see the new naming conventions and task names if you do decide to upgrade - shouldn't be too tricky, but shout if you come unstuck.

1.4 must be from back when the world was still in black and white, so gawd knows what sort of issues that will still have lurking under the hood :)

Dec 17, 2012 at 6:08 PM

Thanks for the quick response but I'm still a bit confused.

Are you saying I should be able to use the latest Compressor dll (2.2.0.0) inside a project which targets the 2.0 Framework?  I tried to do this but it immediately complained that the dll relies on a newer .net Framework (3.5 I believe). 

Coordinator
Dec 17, 2012 at 7:29 PM
Hi,

Yes, 2.x should work with a framework 2.0 project as it targets the 2.0 framework.

We merged the code bases some time back....

Can you provide a self contained example project showing the problem?

Thanks



On 17 Dec 2012, at 18:08, bperniciaro <notifications@codeplex.com> wrote:

From: bperniciaro

Thanks for the quick response but I'm still a bit confused.

Are you saying I should be able to use the latest Compressor dll (2.2.0.0) inside a project which targets the 2.0 Framework? I tried to do this but it immediately complained that the dll relies on a newer .net Framework (3.5 I believe).

Dec 17, 2012 at 8:46 PM

Thanks freeranger.

I was able to get it working after adjusting the code a bit.  Turns out the reference wasn't a problem after all; it was a change in the implementation of a few methods.  The Compress() methods of the JavaScriptCompressor and CssCompressor must have been implemented at static methods in 1.4.  I changed the code to instantiate these objects before calling the methods and everything seems to be working now.

 

Coordinator
Dec 17, 2012 at 8:54 PM

Cool, I was just in the middle of creating a .NET 2 targetted project in VS2010 to see if I could create a problem, but obviously I don't have to now.

Yes, previously there was one static method that did everything (both JS and Css compression), but we refactored it to make the code more testable and to split the tasks out - after all, one has nothing to do with the other, and they pretty much follow discrete code paths, so there is no value in having them together - sure, you would typically want to compress both css and js, but that's "just coincidence" and no reason to lump the code together. 

The current code base should be a bit more SOLID than before, though of course there was a (little bit) of pain with upgrading from the 1.x usage.

One thing you may not have noticed, and it may or may not be of any use to you, is that you can specify compression per file if you wish - so for example if you already have a nicely compressed jquery.min.js file, you can opt NOT to compress this (it is already compressed so you would save little or probably nothing) but still  combine it with your other js files so you get the benefit of fewer round-trips to the server.

Anyway, good to hear you are up and running again.