This project has moved and is read-only. For the latest updates, please go here.

Compression Tweak

Jan 8, 2008 at 6:47 PM
I have once again run into a wall on a project I have been working on using the MLC components. The dependancy for the 3.o framework within the Compression library. Due to outside constraints I will be unable to ge IT staff at my clients location to install the 3.0 framework.

I have created a replacement Compression.cs file that utilizes the DotNetZip library available here at CodePlex. I pulled the DotNetZip library into my SLK 1.3 project and added the signing key to the project and recompiled. This gives me a strong named assembly to use and no requirement for 3.0. I have not tested 64 bit build, as I do not have any 64 bit working going on.

I have placed a ZIP file with the source and strong named binaries onto the DotNetSCORM site if anyone needs a copy.

Jan 8, 2008 at 7:50 PM
Please create and upload a patch to the SLK website and I'll look at including it in a future release. If the code is in good shape and works as expected on x64, we should be able to get it into 1.3.2. I'll update the 1.3.2 Alpha build with the code to make it easy to test.
Jan 14, 2008 at 2:03 PM
Hello Kent, thanks very much for the information on removing the need for Framework 3, I had been looking at your DotNetSCORM project until stumbling accross the MLC within this SLK, still was very handy all the information you had put together using the Java TinyLMS, but MLC does seem an easy and more one architecture solution, thanks to all envolved with SLK, a great source of information on all issues needing to be addressed to use SCORM courses within our own .NET user management system. Thanks for the download, going to update to VS2008 to use latest SLK build and try your ZIP replacement method.

Is this the only requirement for the .NET 3 Framework with SLK?
Jan 15, 2008 at 3:42 AM

Briggsy wrote:
Is this the only requirement for the .NET 3 Framework with SLK?

Yes, it is in the current codebase. I'm getting close to uploading a CMI Tracking Service that allows non-SCORM content to upload CMI Tracking into SLK directly. This Tracking Service uses the new features in .NET 3.5's WCF to provide simple to use REST/POX APIs that can be called from any type of content that can use HTTP POST and XML.

I like Kent's approach because the code to use .NET 3.0's Zip functionality is not very clean because the Zip APIs were not marked Public. The DotNetZip library is a much cleaner interface for zipping/unzipping content. (It also wasn't available when Vandana started this work a while back.)

I certainly hope he uploads it to this project so that we can incorporate the changes into the codebase (nudge nudge).
Jan 15, 2008 at 9:14 PM
I will need to do a bit of work to build a patch. I have a lot of files that have been touched for various reason and a status check on my local tree shows a huge amount of files that would need to go into a patch. I will grab a fresh download and see if I can get one put together. I have not tested this on a full SLK build since I work with the MLC components only right now.

Jan 15, 2008 at 10:48 PM
I have uploaded this patch. One issue I ran into was that the solution files have been edited recently with VS2008, which I do not have. So I was not able to add the reference to the DotNetZip Library in the Compression project. I did however create a make file for DotNetZip and replace the compression.cs file with my version.

Is there a way to read VS2008 solution files with VS 2005? It is going to be next quarter at least before I get VS2008.

Jan 16, 2008 at 4:59 PM

Is there a way to read VS2008 solution files with VS 2005? It is going to be next quarter at least before I get VS2008.

Unfortunately, there is not. The problem I was running into is that each time I sync'd the depot, I was going through a time consuming (and not quite correct, some edits needed to be made) conversion of the project files because I was using 2008. I tried for a week to live in this world, but the pain was too great :-(

I wanted to hold off on the conversion until I had a good solution for using VS Express. That way people like you could side by side install Express 2008 to work on SLK. Unfortunately, I didn't get this done in time. I'll bump it up in the work item priorities.
Jan 16, 2008 at 7:12 PM
I know this thread is drifting just a bit, however from my research on this issue the solution files are the only thing that changes. Would it be possible to create seperate solution files for VS2005 and VS2008? The uptake on VS2008 is not going to be instant for many reasons. Some orginizations are going to hold a bit to finish up other work they are doing rather than migrate everyone at once in the middle of current development. In my case since I work with a wide array of clients I have to continue to support what they are developing with until they all migrate. I have one client still back at VS2003!
Jan 17, 2008 at 6:16 PM

It's not that clean, unfortunately. The settings and resources wizards also need to be 'converted'. The changes are small, but VS complains vociferously if they aren't there. As of 1.3.1 we're also going to have some optional web services which require 2008.

If we work to get the files working on VS Express, will that meet your needs? The MLC components have both ASP.NET and C# and C++ parts to them unfortunately, which means that you'll either need to download three different VS Express products to create a full build your you'll need a full version of VS.
Jan 17, 2008 at 7:14 PM
Here is also something that may be of assistance:
90 day trial downloads of Visual Studio 2008 along with Virtual Machines with VS pre-loaded. You should be able to side-by-side install VS 2008 with VS 2005 and work with all your projects.

Note that VS 2008 has a new feature -- you can compile a project for .NET 2.0, 3.5, or 3.5. This way you no longer need to choose your development environment based on what your runtime environment is going to look like...
Jan 23, 2008 at 9:34 AM
My two cents, for web develoment, VS2008 is worth the upgrade for improved JavaScript dubigging alone!

Especially when developing web based solutions, but bet everyone is waiting for the first service pack before upgrading!!!