locked
Could not find Microsoft.Sharepoint.Library.dll RRS feed

  • Question

  • Hi,

    I have a project with a reference to Microsoft.Sharepoint.dll.

    In the project I try to connect to a sharepoint site but it throws an error that it couldnt find Microsoft.Sharepoint.library.dll.

    Where can I find this library? I take Microsoft.Sharepoint.dll from a server with wss 3.0 but I dont find Microsoft.Sharepoint.Library.dll

     

    Thanks

     

    Monday, March 19, 2007 4:25 PM

Answers

  • People,

    Microsoft says that the only best practice, recommended and supported way to develop for sharepoint is to develop on a server runing sharepoint. So why do you insist on developing on XP? If you cannot install 2003 on your workstation, use VPC, but don't fight with it and try to make it compile on a workstation which is not supposed to be able to do it!

     

    This is one of the most FAQs in this forum, and I hope Microsoft puts the answer at the FAQ part here.

     

    Wednesday, March 28, 2007 6:37 AM

All replies

  • Manuel.

    It's been said a couple of times here in the forum - you cannot run sharepoint code on a non-sharepoint-server.

    The sharepoint code will only run on the sharepoint server. It will not help you to copy the dll to your XP machine - since the DLL doesnt have the framework it needs to run.

     

    Monday, March 19, 2007 9:57 PM
  • Ok, thanks
    Monday, March 19, 2007 10:20 PM
  • When we install WSS extensions for vs 2005; does it not install the required Dlls for WSS including this one? if a developer is creating a web part then from where will he reference the missing dll?

    also if anyone knows whether extension for vs 2005 is available for vb.net?

     

    may thanks,

    bhavtosh

     

    Friday, March 23, 2007 7:11 AM
  • When we install WSS extensions for vs 2005; does it not install the required Dlls for WSS including this one? if a developer is creating a web part then from where will he reference the missing dll?

    also if anyone knows whether extension for vs 2005 is available for vb.net?

     

    many thanks,

    bhavtosh

     

    Friday, March 23, 2007 7:11 AM
  • In my experience, you do not need the SharePoint Library Assembly, even when VS sometimes says it is missing.
    • Proposed as answer by Dharyl Wednesday, July 30, 2008 1:15 AM
    Friday, March 23, 2007 11:14 PM
  • Installing the VS extensions will only help if they are installed on a machine running SharePoint. If you do that then the dlls are already on the machine. If you want to install on another machine, then you may be able to copy over the dlls, put them in the GAC, and hope your environment is close enough to a production environment that the results of your development efforts are more helpful than frustrating. By far the reccommended development environment is on a machine with SP installed.
    Saturday, March 24, 2007 10:03 PM
  • People,

    Microsoft says that the only best practice, recommended and supported way to develop for sharepoint is to develop on a server runing sharepoint. So why do you insist on developing on XP? If you cannot install 2003 on your workstation, use VPC, but don't fight with it and try to make it compile on a workstation which is not supposed to be able to do it!

     

    This is one of the most FAQs in this forum, and I hope Microsoft puts the answer at the FAQ part here.

     

    Wednesday, March 28, 2007 6:37 AM
  • Even better would be if Microsoft fixed the problem. Most people do not develop on Windows Server 2003 and it's an unnecessary restriction.
    Saturday, March 31, 2007 4:47 PM
  • I recently started reading about sharepoint 2007, and all of the books appear to make the assumption that development is occurring on a sharepoint server; however, I've not seen where microsoft makes this explicit as a best practice. Could you provide a link or the title of a book in which this is made explicit?
    Wednesday, April 11, 2007 3:45 PM
  • I've just been experimenting with the walkthough for WebPartsd and found that they work very well.

    However, very quickly I wanted the user to be able to add web parts, in this case RSS panels.

    Obviously the user has to be able to specify the URL of the RSS to display which I enabled with with a propertygrideditor, and it works. Until the page is refreshed (or the mode changed to browse), whereupon all use set properties are reset to null.

    I'm pretty sure this is because WebPartStorage attribute is not set, and the reason for this is that it requires the Microsoft.Sharepoint namespace which I do not have available in the Project | Add Reference dialog. I'm pretty sure this is because I am not running on 2003, and don't have sharepoint.

    Is there anyway to persist WebPart property values without Sharepoint? I seem to have all other WebPart functionality except property persistance, which seems a bit like having a car without wheels.

    (The WebPart functionaility is being used on a standard web site page (with a WebPartManager) not within Sharepoint.)

    Any help would be gratefully received.

    Matt.
    Thursday, May 15, 2008 2:36 PM
  • At the risk of talking to myself, I just found the solution:

    Mark the property with the attribute:

    [Personalizable( )]
    

    This seems to do the trick. I actually want all users to share the same settings
    but one user to be able change the settings, so I'm not sure if this is exactly what I need
    but it answers the basic question of how to persist properties, and confirms that Sharepoint is not needed purely for that purpose.

    Thursday, May 15, 2008 2:49 PM
  • hi,


    I am currently having the same problem on the missing Microsoft.Sharepoint.Library.dll. Doesn't I really need that assembly? I am currently testing using NUnit and I have this problem, I am not gonna make my test go full green if I did not resolve this issue. Do you know where can I find that assembly?



    Thanks,

    dharyl
    programmer
    Wednesday, July 30, 2008 1:14 AM
  • Wow, Ishai Sagi, you're the people tries to think in a box, not out of the box.

    To Manuel5, even Sharepoint cannot run on a non-sharepoint-server, you still can get the Microsoft.Sharepoint.Library.dll. How?
    C:\Windows\Assembly is just like any other folder. It's just speciallized so any other user, or even software developer, can't barely know where is the assembly and freely copied it all.

    But you still can copy it. Sounds great isn't it?

    Open Command Prompt. And point the folder into C:\Windows\Assembly.

    C:\Users\Administrator>cd "C:\Windows\Assembly"

    Because of Microsoft.Sharepoint.Library.dll is a MSIL Assembly, then you will point it to GAC_MSIL folder. type DIR again, and you'll see many of Assemblies folder. Point it into Microsoft.Sharepoint.Library.dll folder. In this folder, there's a folder too.., I don't remember exactly the name, coz full of hexa number. Just type DIR again and point again into that folder. Type DIR, and...........................

    And BINGO! This is what you want, and you can keep it, or copy it into any folder using COPY command.
    • Proposed as answer by mkpriv Wednesday, July 14, 2010 8:02 AM
    • Unproposed as answer by Mike Walsh FIN Wednesday, July 14, 2010 9:31 AM
    • Proposed as answer by jrighteous Thursday, February 17, 2011 3:19 AM
    Monday, August 18, 2008 7:43 PM
  • Microsoft very helpfully renamed this library "Windows[r]Sharepoint[r]Services" [Where the r is the registered trademark].
    It's installed naturally as part of the Sharepoint install on a Sharepoint Server. As one of the respondents here has noted, it's in the 'c:\Windows\Assembly' directory and has Microsoft.Sharepoint .dll as its internal name.
    hth
    Duncan.

    Tuesday, December 16, 2008 1:09 PM
  • Wait...

    ...so to develop for SharePoint Server, I should develop on an actual Windows *Server*? Uhm, what if I don't have a legal copy of Windows Server? Will Microsoft forgive me for stealing it? Or am I to simply pay for it?

    This is one of the dumbest restrictions I've seen in my entire career, and I've seen my share of dumb restrictions. I now officially hate SharePoint. This is ridiculous, idiotic and various other bad things.

    They couldn't even be bothered to show a reasonable error message! As usual, that's just too much for Microsoft.

    God damn whoever responsible for Windows being the most popular OS.

    Thursday, January 29, 2009 10:06 AM
  • Yeah, you would have to develop on an actual Windows Server. Price wise, its not -so- bad... if you have an MSDN subscription, you have all you need, the licenses included are fine for development purpose, and you can easily use virtual machines.

    Also, it has the little perk that Win Server (especially 2008) is arguably the best development platform for ASP.NET app in general, even if you're not using Sharepoint. Thats obviously not always possible, but...

    Thursday, January 29, 2009 9:53 PM
  • But I've ran code on a machine that is not running sharepoint.  It's a matter of referencing the appropriate dlls and that's it. 

    What I don't understand is why force people to develop so that their dev server becomes the production server.  I know, I know, there are ways to do the deployment, but do they really work as they should.

    There is a quote that comes to mind from the Windows Services book from Microsoft Press

    “As a developer, you should ask yourself the following questions: How do you conduct source control management of customization changes? How do you make a customization change to a list definition or a page instance and then move this change from a development environment to a staging environment and finally to a production environment? How do you make a customization change within a site and then reuse it across a hundred different sites? Unfortunately, these questions have very tough answers, and usually you will find that a possible solution isn’t worth the trouble.
    Thursday, March 5, 2009 2:46 PM
  • That quote is referring to ASP.NET sites.  If you read on a bit further it talks about ....

    Fortunately, as a developer you can work at a level underneath the WSS customization infrastructure. To be more specific, you can work with the low-level source files to create underlying definitions for things like lists and page templates. These low-level source files do not live inside the content database, but instead they live within the file system of the front-end Web server. Working at this level is more complex and has a steeper learning curve. However, it lets you centralize source code management and have a more disciplined approach involving code sign-off when moving pages and code from development to staging to production. This approach also makes versioning and reuse of code far more manageable across multiple sites, Web applications, and farms.

    You should look at using Virtual environments, either with Virtual PC or VMWare.  I can't think of any server product that works successfuly on a client machine for development (apart from MCMS).


    My SharePoint Blog - www.davehunter.co.uk/blog
    Thursday, March 5, 2009 4:57 PM
  • Hi Dave,

    I read further :)

    However, what I am complaining about is the fact that developing an application in SharePoint and then redistributing is not very easy.  I've had a lot of conversations with developers and they usually recommend that the dev environment becomes the production environment when a complex application is created. 

    There are ways to do a distribution, however they usually don't work as expected.  I've come across many situations in which small changes in SharePoint simply break up the entire environment.

    Don't get me wrong, I like SharePoint and I work with it on a daily basis.  I'm complaining of the fact that it is so hard to create applications that can be deployed easily.

    Friday, March 6, 2009 2:25 PM
  • This is why **ALL** custom code for SharePoint should be put into features or site templates (or both!) and deployed that way.
    Thursday, April 2, 2009 8:32 PM
  • Radityo, you're great. This is the ANSWER for the QUESTION, not talking about things not being asked like Ishai Sagi did. Thanks, this helped me a lot !
    Wednesday, July 14, 2010 7:25 AM
  • You can do this but you are coding blindly, yes you can use the API but you cannot test or debug the code without deploying to an environment with SharePoint installed on. 

     

    My SharePoint Blog - http://www.davehunter.co.uk/blog

    • Edited by Mike Walsh FIN Wednesday, July 14, 2010 9:29 AM 2010 comment removed. These are pre-2010 forums.
    Wednesday, July 14, 2010 9:21 AM
  • > Radityo, you're great. This is the ANSWER for the QUESTION, not talking about things not being asked like Ishai Sagi did. Thanks, this helped me a lot !

     

    You realise that this is unnecessarily nasty to Ishai Sagi who spent his own time trying to help questioners in this thread.

     

    (Moderator)


    2010 Books: SPF 2010; SPS 2010; SPD 2010; InfoPath 2010; Workflow etc.
    2007 Books: WSS 3.0; MOSS 2007; SPD 2007; InfoPath 2007; PerformancePoint; SSRS; Workflow
    Both lists also include books in French; German; Spanish with even more languages in the 2007 list.
    Wednesday, July 14, 2010 9:31 AM
  • There is a better way that we've been using.  You can install SharePoint on a non Windows Server machine.  There is a great post from bamboo solutions that explains how.  Works on Vista and Windows 7.

    http://community.bamboosolutions.com/blogs/bambooteamblog/archive/2008/05/21/how-to-install-windows-sharepoint-services-3-0-sp1-on-vista-x64-x86.aspx

     

    Tested and works

    • Edited by xavito Wednesday, July 14, 2010 5:17 PM added os
    • Proposed as answer by xavito Wednesday, July 14, 2010 5:17 PM
    Wednesday, July 14, 2010 5:17 PM
  • This is why **ALL** custom code for SharePoint should be put into features or site templates (or both!) and deployed that way.
    And we do in such way.  But here is our situation, we have way too many web parts, theme, custom libraries and third party libraries that require a lot of customization.  Setting up a server is not as easy as deploying features and site templates have a lot of restrictions of what can be included in a template and the size of things included.
    Wednesday, July 14, 2010 5:22 PM
  • You can do this but you are coding blindly, yes you can use the API but you cannot test or debug the code without deploying to an environment with SharePoint installed on. 

     

    My SharePoint Blog - http://www.davehunter.co.uk/blog

    Yes Dave, you're correct. Very blind with this method. The best solution still you must develop it on the Windows Server, but another workarround anyway if you really good in SharePoint code.

    "Jangan bertanya seberapa besar mimpi yang akan kau raih, tetapi bertanyalah seberapa besar dirimu untuk mimpi itu"
    http://otak-otak-it.blogspot.com

    Wednesday, March 14, 2012 4:16 AM
  • If iam correct.....in your GAC folder no refference is found.so that it was throwing error.Try to run sharepoint product wizard once,so it will auto update missing libraries.

    And also a refference sharepoint.dll file will be available in ISAPI folder.but the same require in GAC(assembly folder).

    Please let me the status after runing the wizard.

     

    Wednesday, March 14, 2012 1:08 PM
  • Radityo, your suggestion works perfect.  As you mentioned, all that has to be done is to copy the Microsoft.Sharepoint.Library.dll from the "C:\Windows\Assembly\GAC_MSIL...." folder to the bin folder where you have the Microsoft.Sharepoint.dll and it works.  No need to install Sharepoint on the development box.

    Thanks,
    Adiel

    Wednesday, March 14, 2012 1:43 PM
  • Thank you very much.

    SharePoint made me crazy.

    Tuesday, October 20, 2015 2:57 PM
  • hi

    please answer the question not provide your thinking. we can run a code for sharepoint like a extract list library and... from non-sharepoint machine. sharepoint.library error raise when we want connect to sharepoint service like the SPFarm connection.

    Monday, March 18, 2019 10:02 AM
  • can you paste your code here?
    Monday, March 18, 2019 10:18 AM