We help IT Professionals succeed at work.

SharePoint 2010 and Client Side Automation

Howard Bash
Howard Bash asked
on
I don't have direct access to the server running sharepoint.  So, writing .NET code to do this is out.  

I need to build either a batch application or .NET application that can go through a tree folder of files,  export them to a SharePoint Site adding a list entry for each file,  accumulating a document set and uploading these files.

All this in .NET is cake...  The issue is no Server access outside of SharePoint.

Comment
Watch Question

Top Expert 2011
Commented:
You can still use .NET! Options:
1. Try leveraging the webservices. http://cecildt.blogspot.com/2010/10/upload-documents-to-sharepoint-2010.html http://www.sharepointkings.com/2010/05/upload-document-to-document-library.html
2. Try looking at the Client object Model. http://msdn.microsoft.com/en-us/library/ee857094.aspx

Hope this helps and enjoy the Cake!
Howard BashSenior Software Engineer

Author

Commented:
The code looks interesting.  But I can't seem to locate the SharePoint client dlls that are needed and again I don't have direct server access.
Top Expert 2011

Commented:
you will need to get a copy of "Microsoft.SharePoint.Client.dll and Microsoft.SharePoint.Client.Runtime.dll" from the server. You can get it from any SharePoint box.

I believe you can use this: http://www.microsoft.com/download/en/details.aspx?id=21786
Worse case, install a test version of SharePoint Foundation on a dummy box and you have the dlls. You simply need a copy of these dll to get you started.

Once you have them, my earlier link (http://msdn.microsoft.com/en-us/library/ee857094.aspx) should get you going.

HTH
Howard BashSenior Software Engineer

Author

Commented:
The URLs you sent me are excellent.  I think I'll be able to build what I need to.  Do you know if there are any code snippets that show working with document sets?

Thanks!
Ted BouskillSenior Software Developer
Top Expert 2009
Commented:
Sorry but this won't work.  Having the SharePoint DLLs locally will let you access the API for development and testing but they aren't a remote client and at runtime need to be in the same server as SharePoint itself so your tool will only work if it's installed on the SharePoint server.

You need to write a client to use SharePoint's web services.  You do NOT need the DLLs to do that.
Howard BashSenior Software Engineer

Author

Commented:
The client dlls allow me to create lists and more though from the client machine.  I have done so.  I would have thought that the doc set is a list as well.
Howard BashSenior Software Engineer

Author

Commented:
Not sure what you're saying doesn't work.  Once I have the client dlls I can write and read from the SharePoint server.
Howard BashSenior Software Engineer

Author

Commented:
I have hit a wall.  With the SharePoint 2011 client dlls added as references, I can read/write (not sure about delete) lists.  But I cannot make a libary folder and upload a document.  I think it's a rights to noodle with the file system issue.
Top Expert 2011

Commented:
Ted BouskillSenior Software Developer
Top Expert 2009

Commented:
It's because the DLL's on your local machine don't have the access privileges because they are working remotely.  You have to use the web services.
Howard BashSenior Software Engineer

Author

Commented:
Is it the DLL's or my rights to the server?
Ted BouskillSenior Software Developer
Top Expert 2009

Commented:
DLL's cannot be remotely loaded into the memory of the EXE on the SharePoint server.  That is the way applications work at the operating system level.  The only reason you even get some functionality is a fluke because SharePoint itself was designed to do some work using web services even on the same server.  So, when you try some of the functions in the DLL it's likely using web services in the code.

Contact Microsoft Support and I guarantee they will state that using the DLL's remotely to manage SharePoint will not work properly.  You have to use the web services to work remotely.
Howard BashSenior Software Engineer

Author

Commented:
Indeed.  However using the SharePoint client DLLs they run on for example,  my PC.  I am not using nor attempting to use DLLs remotely.  I don't think I stated that either...
Ted BouskillSenior Software Developer
Top Expert 2009

Commented:
I think you are missing the point.  The DLL's are loaded by your EXE but they are not being loaded by the SharePoint EXE on the server.  Therefore the do not have full access to the SharePoint API on the SharePoint server.  They link to your client EXE but not to the SharePoint Server EXE.

So, you are running a crude simulator with partial functionality.  Any of the code you try to run in the local client DLL's that triggers consumption of a SharePoint web service will work if the web service permissions are valid, however, you will never be able to fully utilize the SharePoint API on the local client because the SharePoint DLL's are NOT being loaded by the SharePoint EXE.

Once again, please contact SharePoint technical support and they will confirm what I am telling you.
Howard BashSenior Software Engineer

Author

Commented:
What is the purpose of the SharePoint Client API?
Ted BouskillSenior Software Developer
Top Expert 2009

Commented:
Obviously to manage SharePoint however, the API has to work within the boundaries of the technology.  Web services IS an API and that is what I'm recommended you use.  You are trying to use the runtime API remotely which is not how it was designed or can work.

SharePoint is designed to work as a web application.  Binaries for SharePoint are installed on servers which are then joined to a running SharePoint farm by the Farm Administrator.  The binaries then have the necessary privileges to run the full API and work directly with the SharePoint databases which hold content for the farm.

Any code you write on a client is not a member of the SharePoint farm without a full running copy of all the binaries, therefore because SharePoint has not been designed to support DCOM your client can only access the farm via HTTP protocols which includes web services.
Howard BashSenior Software Engineer

Author

Commented:
Slowdown.  Let me repeat
"
I have hit a wall.  With the SharePoint 2011 client dlls added as references, I can read/write (not sure about delete) lists.  But I cannot make a libary folder and upload a document.  I think it's a rights to noodle with the file system issue.
"
Client DLLs were being used...  Not sure where you get the notion I was using the server side DLLs on my desktop.  

I think I mentioned CLIENT SIDE DLLs four or more times...

I appreciated the wisdom though.




Ted BouskillSenior Software Developer
Top Expert 2009

Commented:
I know you are using client side DLLs and I keep telling you that will not work and is the wrong way to solve this problem.  The DLL's you are using were NOT intended for remote connectivity to a SharePoint server.  They were designed to only work on the SharePoint server.  If you do not believe me, ask Microsoft.

For some reason you think it's valid to use the DLL's that were only intended to be used on the SharePoint server on a client and I can't seem to get you to understand that point.

Your profile states that you have decades of computer experience so I was trying to explain the issue from one computer professional to another.

I'm putting in a request for attention to EE moderators.  You have been given the correct answer which is: "You cannot use the SharePoint DLL's in a client application and must use SharePoint web services instead"

Ted BouskillSenior Software Developer
Top Expert 2009

Commented:
Points should be split between http:#37244516 and http:#37247765
Howard BashSenior Software Engineer

Author

Commented:
This quote: Summary:  Learn to use the SharePoint Foundation 2010 managed client object model to write applications that are based on the .NET Framework and access SharePoint content from clients without installing code on the server that runs SharePoint Foundation 2010.

from this URL: http://msdn.microsoft.com/en-us/library/ee857094.aspx

I'm not seeing why you think that I cannot use the Client api to access a SharePoint site (see quote and URL).  I believe the entire issue I am having creating folders/uploading to the server are a rights issue, not components/technology.

Where am I missing here and how does your comment:
"
For some reason you think it's valid to use the DLL's that were only intended to be used on the SharePoint server on a client and I can't seem to get you to understand that point.
"

make sense as the "CLIENT" api is for usage on a client machine.
Howard BashSenior Software Engineer

Author

Commented:
Also,  do show me where I am suggesting using server side components in this thread as you seem hung up on that notion.
Top Expert 2011

Commented:
So where exactly are you stuck? you want to create folders and upload files in SP using the Client object model.

My earlier links showed how to add files.

Add folder:
http://social.technet.microsoft.com/Forums/sr-Latn-CS/sharepoint2010programming/thread/8bd508f5-50dc-443b-84fd-e375ec32d1ce

Add Files:
http://blogs.msdn.com/b/sridhara/archive/2010/03/12/uploading-files-using-client-object-model-in-sharepoint-2010.aspx

Make sure the account you are using to connect has enough access to the server... that's the first requirement. You need to have atleast contribute rights to the site and the list to create list and add folders/files to it.
Top Expert 2011

Commented:
This article does a decent job in explaining the basics of SP COM, i hope you will find it helpful:
http://www.codeproject.com/KB/sharepoint/SP2010ClientObjectModel.aspx
Ted BouskillSenior Software Developer
Top Expert 2009

Commented:
OK, first off, the link provided in comment http:#37354913 is from December 2009 which was months before the official SharePoint 2010 release date.

In fact, one of the links in comment http:#37354958 was posted before SharePoint 2010 was officially released.

The link in comment http:#37354965 is using an example with the client model in a web part deployed to the SharePoint farm, not in a stand-alone client application.

I've attended an invitation only SharePoint 2010 Deep Dive in Redmond at the Microsoft campus to spend time with the SharePoint 2010 product team including lead engineers from various sub-groups in SharePoint because my employer was a strategic partner with the group.  They made it clear to me that you cannot believe all of the MSDN content because a lot of it was published while still in Beta and features were dropped or changed at the last minute and the content may not reflect the actual functionality.

Many features don't get completed removed when the product goes from Beta to Release but aren't supported or even recommended for us.  For example, the Microsoft product team strongly recommended we do not do an in place upgrade even though that feature is available.

As I said in an earlier comment, the client object model will work with limited features and is actually using SharePoint web services for remote access to the SharePoint installation and has practical limits.  The SharePoint product team recommended to me in person that we avoid building client applications using the object model and focus on deploying all code on the SharePoint installation.

You've said you hit a "Wall" and that might be the limit of what can be done remotely.  If you think it's a right's/permission issue then run the client EXE using a Windows account that has Site Collection Administrator permissions for the SharePoint website.  If the EXE fails, then it's not a rights/permission issue.  If it works, then you will have to figure out the permissions required for the remote client EXE to have in order to run remotely.  However, as I've stated I was told in person my the Microsoft team that they don't recommend it in most cases.