64 Bit Support

Topics: Developer Forum
Dec 12, 2006 at 3:18 AM
Will we see a 64 bit version?
Coordinator
Dec 14, 2006 at 10:23 PM
Excellent question. As far as I know, what keeps SLK from being 64-bit clean is the x86 native Compression.dll that's used to manipulate Zip files. I filed a work item to replace this code a while back because it's also the only code in SLK that the source code is not available for. The assembly was licensed by Microsoft and the terms of the license allowed binary but not source redistribution.

There's a Zip library in .NET 3.0 now, but it's marked 'internal' and is under the Microsoft.Internal namespace of the WindowsBase assembly. You can see this code via a decompiler like .NET Reflector, but you cannot call it easily because it's marked internal. The only way to call into it is via the System.IO.Packaging APIs which manipulate the new OPC standard introduced with XPS/Office 2007. I looked into these APIs and while you can manipulate a Zip file with them, they require specially formatted Xml files in the Zip to work. We could add these to SLK packages, but we wouldn't be able to open a SCORM standard package unless it was modified to add these file. Ironically, these OPC Xml manifest files are doing basically the same thing that an IMS Package Manifest does, just different schema :-)

There are sneaky ways to be able to call into internal (and even private!) code in .NET as long as you're running in full trust. You can use Reflection or even the Visual Studio PrivateObject helper that was created for unit testing. Ergo, we might be able to get x64 compatibility by, ah, bending the rules a bit. Anyone feeling particularly bendy today?
Coordinator
Jan 16, 2007 at 1:17 AM
FYI, I've been playing around a little here and I've confirmed that I can open, read, and modify a generic Zip file (as created by WinZip) using the internal ZipArchive APIs. To get a feel for how you do this here's a little snippet:

Type typeZipArchive = Type.GetType("MS.Internal.IO.Zip.ZipArchive, WindowsBase, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35");

object zipArchive = typeZipArchive.InvokeMember("OpenOnFile", BindingFlags.NonPublic | BindingFlags.Static | BindingFlags.InvokeMethod, null, null, new object[] {
archiveName, FileMode.Open, FileAccess.ReadWrite, FileShare.None, false
});

IEnumerable zipFileInfoCollection = (IEnumerable)typeZipArchive.InvokeMember("GetFiles", BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.InvokeMethod, null, zipArchive, null);

- jcb
Jan 18, 2007 at 11:50 PM
I posted this note to the work item, but will post the code here. By referencing the java.util.zip namespace we get full Zip File manipulation capabilities. I build a wrapper to replace the Unzip function in compression.dll, What do we need to do for Unbundle?

using System;
using System.Collections;
using java.util;
using java.util.zip;


public class Compression
{
public static void Unzip(string zipFileName, string destinationDir)
{ //zipFileName=Compressed File path
try
{
java.io.FileInputStream fis = new java.io.FileInputStream(zipFileName);
java.util.zip.ZipInputStream zis = new java.util.zip.ZipInputStream(fis);
java.util.zip.ZipEntry ze2;
sbyte[] buf = new sbyte1024;
int len;
string fileName;
while ((ze2 = zis.getNextEntry()) != null)
{
fileName = ze2.getName();
string newpath = System.IO.Path.Combine(destinationDir,
System.IO.Path.GetDirectoryName(fileName));
System.IO.Directory.CreateDirectory(newpath);
fileName = System.IO.Path.Combine(destinationDir, fileName);
java.io.FileOutputStream fos = new java.io.FileOutputStream(fileName);
while ((len = zis.read(buf)) >= 0)
{
fos.write(buf, 0, len);
}
fos.close();
}
zis.close();
fis.close();
}
catch
{

}
}


}



Feb 2, 2007 at 12:10 PM
Hi, Firstly many thanks for the excellent work done on the SLK and for releasing it to the community. I have several customers moving from SPS2003 to MOSS2007 and are introducing the SLK as part of Learning Gateway, or bespoke builds. A couple have asked about the transition to 64bit. They are all using 64bit MOSS / windows / hardware, but are connerned that the compression issue means they should not deploy on 64bit. Do you know of any other issues with 64Bit deployments of SLK?
Mar 23, 2007 at 6:54 PM
This discussion has been copied to Work Item 9115. You may wish to continue further discussion there.
May 17, 2007 at 2:59 PM
I am trying to compile the version of SLK with 64bit support but I am encountering a similar problem that I noticed on another thread where I get the error:

The project type is not supported by this installation.

When trying to build CompressionUnitTest. I am running Visual Studio Professional 2005.

Would anyone be able to help me with this as I am trying to install SLK on a 64bit Sharepoint solution, and would like to avoid having to roll back to 32bit if at all possible. Either a solution to the error, or perhaps someone could send me a compiled version of this source code?

Thanks.
May 17, 2007 at 4:18 PM
I have no idea if this will help as I am not a coder, but I did notice the following over on the issue tracker:

http://www.codeplex.com/SLK/WorkItem/View.aspx?WorkItemId=9115

Changeset 20321 provides 64 bit support for SLK. To build a 64-bit solution, build the source code with the 'TARGET_ARCH=x64' parameter during 'nmake'. This changeset will hopefully be part of an official release soon. The community may be polled for a decision on this.
May 17, 2007 at 4:38 PM
Edited May 17, 2007 at 4:40 PM
Hi TalwynHayes,

The CompressionUnitTest does not need to be compiled to generate working SLK binaries for a 64-bit machine. Someone here had pointed out that compiling unit tests requires a higher version of Visual Studio. We will remove this in the next changeset. For now, you could just comment out the compilation of this project. To do this,

a. If you are using the makefiles (nmake) to build the binary, remove (or comment) the line which has a reference to CompressionUnitTest in the makefile at the path, /slk/src/Compression/makefile (there are 3 such lines in the file). If the source is built after this change, you will not see this error

b. If you are compiling the binaries from Visual Studio, remove the project reference corresponding to 'CompressionUnitTest' from the 'Compression' project.

Hope this helps.
May 23, 2007 at 3:41 PM
Hi VandanaPonnuru

Thank you for your help. Removing the CompressionUnitTest seems to have helped with the compile. I was able to deploy SLK to the 64bit sharepoint server that this code was compiled upon.

However, I don't seem to be able to deploy the solution to a different server. I copied over the "solution" folder, ran Addsolution and DeploySolution, but the deploy fails with the message DeploymentFailedFileCopy.

What am I doing wrong? I would rather avoid having to install visual studio on the sharepoint server just to be able to add SLK...

Have you any idea when there will be a 64bit release available?

Thanks.

May 24, 2007 at 8:44 AM
I have a MOSS farm running 64bit Windows 2003 Server and 64bit MOSS across 3 servers. I would like to deploy SLK on the farm but understand there are some issues surrounding SLK and the 64bit architecture. Could someone please clarify whether we are talking just about the 64bit version of MOSS that SLK has an issue with or is it the 64bit version of Windows 2003 Server. I don't want to roll back to a 32bit version of MOSS and find SLK still has issues because I am running the 64bit version of Windows 2003 Server. Any help on clearing this up would be much appreciated. Any advice on what the specific issues are on the 64bit platform would be helpful too.

Thanks
May 25, 2007 at 12:55 PM
TalwynHayes,

I can help you with that problem. This is not a 64-bit issue but something one encounters with every compiled build. The 'DeploymentFailedFileCopy' simply happens because of strong name verification. The build that is generated by compiling the source code is not 'strongly signed' (unlike an official release). The machine on which this build is deployed should add a special entry for the dll (through sn.exe) to tell the system not to do strong name validation. The complete command is sn.exe -Vr *,abc4ed181d6d6a94.

However, this may still not solve your problem. It baffled us for quite some time too. It turns out that SharePoint caches this strong name verification exclusion list. In order to push in this new entry, the WSSAdmin process should be restarted. Check a useful comment by user JTimblin in the SLK FAQ section regarding the same.


When we encountered this on one particular instance, it so happened that even restarting the wssadmin process didn't help in clearing the cache. While this may not be required, if restarting the wssadmin process doesn't clear the cache, the easiest alternative is to just re-install SharePoint (your setup permitting such a thing)
May 25, 2007 at 1:28 PM
Edited May 28, 2007 at 11:16 AM
Hi VirinderAulakh,

The latest SLK release, 1.0.799.0, contains a native dll compiled for the 32 bit platform and hence does not run on a Windows 64 bit server (It is not a requirement on MOSS). Recently, the code was fixed, and SLK is now capable of running on the 64 bit server without issues. However the binaries were not built and no official release was made following this change. We are working on getting some build infrastructure ready for the 64-bit release and therefore an official release should be out within a couple of weeks.

SLK is very easy to build and therefore one option is to make your own binaries until an official release is available. All information pertaining to the same is available on this thread. To consolidate,

a. If you are not running Visual Studio team edition, do not compile the CompressionUnitTest (details in one of the posts)
b. Run SkipVerification.bat (found in the root of the SLK source) which disables strong name verification (this has to be done on all machines that a locally built version of SLK is deployed to)
c. Build code by running, 'nmake TARGET_ARCH=x64' (in the root directory of SLK source)

May 26, 2007 at 4:12 PM
VandanaPonnuru,

Thanks for your help, you were right about it being the strong name verification, although I had already run skipverification on the server I was trying to deploy on, restarted WSSadmin and even rebooted (I saw the tip in another thread). However, as it was a farm with two front end servers it was attempting to deploy on both, which I didn't realise until checking the event logs on the second server. I had not run skipverification on the second server! Once I did that and verified using Gac.bat, the deploy succeded.

Thanks
Jun 26, 2007 at 9:47 PM
Hi VandanaPonnuru;

I am also trying to install on a Win2003 64-bit platform.
I have followed all the suggestions here, including:
* Not compiling CompressionUnitTesting,
* SkipVerification (successfully)
* Reinstalling MOSS (not the MOSS_Config database though) and I still cannot build. I am getting the following error:
What should I do?

Done building project "SlkDll.csproj" -- FAILED.
========== Build: 3 succeeded or up-to-date, 1 failed, 0 skipped ==========
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 8\Co
mmon7\IDE\devenv.COM"' : return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 8\VC
\BIN\amd64\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 8\VC
\BIN\amd64\nmake.exe"' : return code '0x2'
Stop.

Build completed in: 0:20

__________ Error Summary __________

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets(3089,13):
error MSB3073: The command "gacutil -i C:\dev\SLK\Slk\Dll\bin\Debug\Microsoft.S
harePointLearningKit.dll" exited with code 1.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 8\Co
mmon7\IDE\devenv.COM"' : return code '0x1'
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 8\VC
\BIN\amd64\nmake.exe"' : return code '0x2'
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 8\VC
\BIN\amd64\nmake.exe"' : return code '0x2'
___________________________________
--
"Mention TARGET_ARCH=<input architecture> as the first parameter"
"Example: fmake TARGET_ARCH=x64 rel"
--
Jul 3, 2007 at 6:50 PM
We must have 64 bit support asap