This project is read-only.

Is there plans for an Optimized .Net 4.0 Compiled Library release?

Aug 10, 2011 at 10:05 PM

I was wondering if there are plans to release a .Net 4.0 version of the libraries? One that is optimized for .Net 4.0 to take advantage of the new language features and functionality.  Examples would be things like option arguments and using TPL where it can optimize performance.  Plus just having a CLR4 compiled library is optimized better than a CLR2 compiled library so just release official DLL's that are compiled CLR2 and CLR4 would be a great step towards this.

Aug 11, 2011 at 6:14 AM

Yes - I thought about going to some of the .NET 4.0 features, but ... there are a bunch of people still using .NET 2.0, and I'm hesitant to fork the source code in order to support both. So I've been a laggard on that point.

Beyond the optional arguments stuff, which is nifty, there are some cool things possible with parallel tasks, too, which I would like to exploit.  But for now I've decided to defer that work.


Aug 11, 2011 at 4:30 PM

You could use Preprocessor Directives so that you are not actually forking the code base, it just compiles sections of code depending on which .Net is being targeted.  Also like I said a good start would be to just release official and strong named version of the current ones as .Net 4 and .Net 2.0 side by side.  This requires nothing special but changing the targeted .Net.  From there as time permits you could migrate areas of the code to the new .Net features using Preprocessor Directives.

Aug 11, 2011 at 4:44 PM
Edited Aug 11, 2011 at 4:45 PM

Sure I could use preprocess directives, but it's still two output products.  There's parallel development, parallel testing, ...  Right now DotNetZip entails 3 libraries - bzip, zlib and zip, and 3 platforms - CF, SL and .NET.  There's just one of me. I'm very hesitant to expand scope for that reason.

Aug 11, 2011 at 4:58 PM

Understood, but just doing only .Net compile and strong name with no code changes at all would be a great step forward.  Just being able to use CLR 4 natively instead of CLR 2 compatibility mode in CLR 4 is a huge improvement on performance.  Also using the CLR 4 should give you better profiling abilities to make it easier to improve perfomance and memory usage in the future if needed. This is just modifying the build scripts and you could automate a process that outputs all 3 libs for all 3 platforms for both CLR's.

Aug 11, 2011 at 5:00 PM

Is that true?  I did not know that CLR2 assemblies performed more slowly in CLR4 apps. Can you refer me to some documentation on that?

If it is merely a matter of recompiling, I can handle that no problem.  You're right there's not much cost there.

Aug 11, 2011 at 5:16 PM

There are compatibility issues sometimes, I am not finding any with yours, also since CLR 2 is "compatibility" based and not native CLR 2 it can never be as fast as CLR 2 outside of the CLR 4 runtime its like expecting a Guest VM to be faster than its host.  People have "claimed" there "should" be no difference and there may not be any on small applications. 

However, we have noticed this with our .Net 2 stuff as we are migrating to .Net 4 and because of the performance and compatibility issues we had running CLR2 stuff under CLR4.  We however are not a small little app, we have a enterprise class application. We decided to force a migration of everything we have in our next major release to be .Net 4 period instead of just a few parts.  This increased or work load and will most likely effect our release date, but it had to be done to deal with the issue.  I looked and I couldn't find anything about others talking about this issue public but I have seen it with my own eyes. So there may not be many private company going out and talking about it for .Net Enterprise applications.

Also I do know that CLR4 apps in my testing seem to have better memory usage and a smaller memory footprint simply by switching from CLR2 or CLR4 with no code changes.

Also .Net 2.0 is going to be 6 years old this November so its just getting old, and people really need to move on. :) It taking us a long time to release this and finally make the jump.

Aug 11, 2011 at 5:49 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.