SharePoint 2010 and Client Side Automation
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.
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
you will need to get a copy of "Microsoft.SharePoint.Clie
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
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
ASKER
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!
Thanks!
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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.
ASKER
Not sure what you're saying doesn't work. Once I have the client dlls I can write and read from the SharePoint server.
ASKER
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.
The Client Object Model is very powerful but has some learning curve. These should help:
http://dotnetbyexample.blogspot.com/2011/03/sharepoint-client-object-model-sites.html
http://blogs.msdn.com/b/sridhara/archive/2010/03/12/uploading-files-using-client-object-model-in-sharepoint-2010.aspx
http://ranaictiu-technicalblog.blogspot.com/2010/03/sharepoint-2010-manage.html
http://dotnetbyexample.blogspot.com/2011/03/sharepoint-client-object-model-sites.html
http://blogs.msdn.com/b/sridhara/archive/2010/03/12/uploading-files-using-client-object-model-in-sharepoint-2010.aspx
http://ranaictiu-technicalblog.blogspot.com/2010/03/sharepoint-2010-manage.html
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.
ASKER
Is it the DLL's or my rights to the server?
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.
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.
ASKER
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...
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.
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.
ASKER
What is the purpose of the SharePoint Client API?
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.
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.
ASKER
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.
"
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.
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"
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"
Points should be split between http:#37244516 and http:#37247765
ASKER
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.
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.
ASKER
Also, do show me where I am suggesting using server side components in this thread as you seem hung up on that notion.
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.
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.
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
http://www.codeproject.com/KB/sharepoint/SP2010ClientObjectModel.aspx
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.
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.
ASKER