5

I am developing on a 64bit version of Windows 7, running MOSS (SharePoint), this is my dev machine.

Now when I deploy my web service app to a test server Windows 2003 32bit (no Sharepoint installed) I get this error.

Could not load file or assembly 'Microsoft.SharePoint.Library, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' or one of its dependencies. The system cannot find the file specified

The DLL has clearly been copied to the bin directory (Microsoft.Sharepoint.dll).

Any ideas?

JL.
  • 78,954
  • 126
  • 311
  • 459
  • 2
    The (no Sharepoint installed) is the key. Somewhere you're referencing the SharePoint DLL, and it doesn't exist on a server without SharePoint. My main question is how you got MOSS installed on a client OS - I thought that was impossible. – Harper Shelby Oct 01 '09 at 19:00
  • @Harper - read this - http://readmystuff.wordpress.com/2009/09/05/how-to-get-sharepoint-2007-to-run-under-windows-7/ – JL. Oct 01 '09 at 19:01
  • Why don't you install SharePoint on your test server? – FallenAvatar Oct 01 '09 at 20:22
  • @TJMonk - its more of a test -> production server, the app is supposed to talk to sharepoint remotely, so I've had to change my code to use the web service model instead. -4 days worth of work. – JL. Oct 02 '09 at 07:38
  • @JL: You might want to subtract a few more days once you get into using the web services. You will probably have to write some custom ones of your own. – Alex Angas Oct 02 '09 at 09:19

6 Answers6

7

If you are using sharepoint dll's it will only work on a machine with sharepoint installed.

Even if you managed to hack it and get it to work, you would probably be breaking a license agreement.

Shiraz Bhaiji
  • 64,065
  • 34
  • 143
  • 252
  • 4
    @JL: I would guess *pretty darn sure*. SharePoint isn't exactly freeware and I can't imagine that MS would appreciate bits of it being broken out for use in another app. – NotMe Oct 01 '09 at 20:05
  • 1
    Most of Sharepoint that people actually use is just WSS. Comes free with a windows server license. – Chris Ballance Oct 05 '09 at 01:57
  • 1
    @Chris, Yes but then you would install WSS, not just copy in a dll – Shiraz Bhaiji Oct 05 '09 at 06:39
  • if this is the case, then how would a user be able to submit a file from, say, an ASP.NET app to the network's SharePoint if the software isn't installed on their PC? – Freerey Feb 10 '20 at 16:15
5

There is a way to load Sharepoint libraries in a development console with windows XP, Vista or Seven.

See here: http://fernandof.wordpress.com/2008/02/11/how-to-install-the-sharepoint-2007-vs-2005-extensions-on-a-workstation/

[O]pen the regedit and create the following keys and the string value:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0]

"Sharepoint"="Installed"

That’s it! You have fooled the installer into running on a workstation. Easy. I also recommend adding the core SharePoint assemblies into the [GAC] using gacutil. Those assemblies can be found by default in any [SharePoint] machine under the folder: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\ISAPI.

Peter O.
  • 32,158
  • 14
  • 82
  • 96
Eli
  • 51
  • 1
  • 1
1

This is almost certainly a dependency issue. The DLL is dependent on another DLL which isn't in the GAC or on the probing path. The two tools you need to figure this out are FUSLOGVW.EXE and Process Monitor

Fusion Log viewer will allow you to look at assembly bind successes and failures as your application loads. It's part of the Windows SDK.

http://msdn.microsoft.com/en-us/library/e74a18c4(VS.71).aspx

FUSLOGVW needs admin privs to run correctly.

If that doesn't work another tactic is to use Process monitor to look at which files aren't getting loaded and which folders are being searched.

http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

However. Without SharePoint installed I wouldn't expect this to work.

Ade

Ade Miller
  • 13,575
  • 1
  • 42
  • 75
  • +1 for the new knowledge of this tool. But I think the issue here, as you suspect too, is that MOSS has to be installed – JL. Oct 02 '09 at 07:37
1

From MSDN: "The CI build environment for the Training Management application does not perform any tests that require a live instance of SharePoint. All the unit tests use mocks that replace the actual SharePoint instance and services. Building the code and running the unit tests only requires that the following SharePoint assemblies are installed on the CI build server:

Microsoft.SharePoint

Microsoft.SharePoint.Security

Microsoft.SharePoint.WorkflowActions

Supporting referenced assemblies"

http://msdn.microsoft.com/en-us/library/ff647619.aspx

Martin R-L
  • 4,039
  • 3
  • 28
  • 28
0

Don't mix 64-bit and 32-bit for dev / testing / production. This will never work reliably if at all.

Chris Ballance
  • 33,810
  • 26
  • 104
  • 151
  • +1 for this point, because in SharePoint you want to try minimize environment differences, but ofc in traditional .net development in my experience its not a huge problem because you can output using the ANY CPU build model. – JL. Oct 02 '09 at 07:36
  • @Chris: I've been doing this for almost a year with web parts, event receivers, etc... What problems have you found? – Alex Angas Oct 02 '09 at 09:18
0

Well what about other dlls referenced by the Sharepoint dll? With long dependency chains it can be quite difficult to diagnose these sort of problems. In such situations I find the fusion log viewer extremely useful. It is a part of framework SDK - open the SDK Command prompt and type fuslogvw. It is pretty obvious from there

mfeingold
  • 7,094
  • 4
  • 37
  • 43