I've developed an outlook addin in vs2013. The development machine has sharepoint installed. My code has:
using Microsoft.SharePoint;
But when I run this code on a client machine it shows an error.
enter image description here.In some sites they suggest using Microsoft.SharePoint.Client.dll. Can anyone help?
This won't work as you expected. Microsoft.SharePoint.dll is a server side library which is part of Microsoft SharePoint and hence can neither be referenced nor used otherwise in a client-side environment such as an Outlook add-in.
What you are looking for is Client-Side Object Model, or CSOM for short. However, developing CSOM apps is a completely different story, needs slightly different knowledge and skills. The bad news is most of your SharePoint-related work will have to be redeveloped almost from scratch.
If your SharePoint integration isn't heavy, you might be able to achieve what you want with SharePoint's web services, either REST or SOAP. There an article on MSDN providing insight to various types of SharePoint APIs and providing guidance which API to use in what situation. You shoudl read this first.
we can't use using Microsoft.SharePoint; in sharepoint not installed system.
we need to use using Microsoft.SharePoint.client; for client system and use client object model code.
Related
I am looking for the best way to add support for a REST based Web Service to an MFC C++ Application. This is legacy code that has been around a long time.
I need to have the Application provide the Web Service. I've researched this, and the articles are about consuming Web Services in a C++ App. I envision having to monitor a port and respond to the HTTP requests. It would probably make more sense to tie in with WCF and IIS, but I am not sure how to move forward.
I already have a tool of "making" this App into a Windows Service. I realize it would be better to have a "real" app, and this is what I have to work with. There is so much logic in this code and we are limited in development time, so we are taking the fastest approach possible. We also cannot use DCOM, as the Web Service will be called by a Linux based system.
Any suggested articles would be much appreciated.
For C++ you can test two libraries WSF/C and gSoap, another alternative is to develop it with C# and WCF , and communicate between C# and C++ using C++\CLI.
I use the Poco Net c++ library for this as it supports both HTTP client and server functionality. I considered various other libraries including Boost based stuff, but other than Poco I struggled to find everything I needed in one tidy package. It also has some easy to use mutex support which became essential for me as soon as I added a web server front-end to what had previously been a simple single threaded console app. Poco is cross platform but I mainly use it windows and it has served me well to date. I'm not very clued up on MFC so I don't know how it would get on in that department though.
I am having a desktop application which having a UI interface made in Qt linked with a library which is doing all the calculation stuff. Values from UI is taken and pass to the API's in the DLL to get the output which is shown on Screen.
Now i want to do the same thing by transferring my application UI to a web page so that people can access the tool from anywhere without any installation process.
I want to retain my c++ DLL code so i don't have to do a lot of work. I am thinking of just converting this DLL to a C++ server by any communication Process(Sockets). I want to host this application on my company's website. (We have to make the website also so we are open to any set of tools).
I want to know what will be the best set of tools to do this stuff. Also there will be lot of data exchange between the webpage and server so the wholething should be optimized also. I goggled a bit and find stuff like silverlight and ASP.NET, But i am still not very clear which option will be more suitable.
I am a c++ programmer with no web application development experience. I am open to learn any new technology.
Thanks
Why not use Qt on the web directly? There are several projects like this one: http://qtwui.sourceforge.net/
There is a netscape plugin that will host a QT application and an ActiveX control wrapper on the QT website. You could use one of those to wrap your application. Note that this approach would require the user (or their administrator) to download and install the plugin.
An alternative approach might be to run your application through a remote desktop such as XVNC, NX or an RDP based layer. IIRC browser based remote desktop clients are available for most such protocols.
A few options:
pick a messaging/queue implementation (like http://www.zeromq.org/) and provide a service
implement a Windows Web Service if you want to be more enterprise friendly: http://msdn.microsoft.com/en-us/magazine/ee335693.aspx
I would not expose the implementation on the internet. Enough to have a simple buffer overflow and the machine can be taken over quickly. Adding a layer between the app and the web provides an easy way to validate input, access, stats ...
You should be able to use your DLL from an wt or cppcms application. Then you do not have to learn something new and can just use C++.
The way I'm currently doing this is with Boost.Python + django
I am looking for any information on the Microsoft TFS Web Services. First I know accessing the Microsoft TFS Web Services directly is not supported and Microsoft provides no documentation for doing this. Therefore I am not expecting any Microsoft support or assistance here.
I know all about the .Net API available for TFS which only works on Microsoft Operating Systems. I have used these many times on Windows, however I need to do non-Windows work to access TFS, I cannot use .Net and I cannot use a Proxy (or "shim") to be installed on a Windows computer to provide Web Services for the .Net API.
I know Teamprise reversed engineered the web services and they successfully used this knowledge to make a very good cross platform Team Explorer and command line implementation in Java to access TFS. So good in fact they were purchased by Microsoft and the product rebranded and rereleased as Microsoft Visual Studio Team Explorer Everywhere.
I have also tested the .Net API against Mono on several non-windows platforms and they are not compatible. The initial NTLMv2 authentication is using calls not supported by Mono. They appear to be, understandably, making Win32 specific calls for NTLMv2 support.
Therefore before I go to the trouble of reverse engineering them for myself, and dealing with NTLMv2 to do it. I am hoping that there is some hidden or buried information on the web that someone may have documented some portion of the web services for TFS from 2005, 2008 and/or 2010.
Please no comments or posts about how this is not recommended or supported by Microsoft, that I should find a way to use the .Net API, or suggesting the Proxy/Shim is the best solution. I am fully aware of the Microsoft's official stance on this, and what the supported workarounds would be.
I'm not aware of any documentation for the TFS web services, but I can share some tips on calling them.
The NTLM authentication you mention is really a separate layer: you must authenticate to IIS before it lets you call TFS web services. I'm not aware of any Open Source software that will do NTLM auth for you, but TFS 2010 makes it easy to enable "Negotiate" authentication (SPNEGO on Wikipedia, Authentication by using Kerberos Ticket on MSDN). Negotiate supports both NTLM and Kerberos subsystems, and there may be some existing software you can use to drive it using the system's Kerberos libraries (I think curl does it). If you had to build it yourself, it would probably be easier to go the Negotiate-with-Kerberos route.
Once you're authenticated, you can start calling services. Start by pulling down the WSDL for each service (stick a "?wsdl" suffix on each endpoint URI). Hop over to where TFS is installed and explore the web application directory for endpoints. There are several versions of some endpoints for back compat with TFS 2005 and 2008, but usually new versions are not redundant (they add new stuff). You might have a favorite SOAP client library already (there are many for Java), but I can't really recommend any because we wrote our own at Teamprise.
Services like version control, build, and common structure are easy to discover via WSDL. Most the operations have obvious names, but the complex type fields are often super-abbreviated. The best way to figure which methods to call when is to watch the VS TFS client or TEE with Fiddler or Wireshark or some other HTTP inspection program. TFS VC does do things like file uploads/downloads outside the web services (watch a network trace to see the multi-part MIME upload process and be sure you're sending the right values if you implement this).
A note of caution on the work item tracking web service: this one is going to be extremely hard to master. The WIT design involves the client pre-querying the server for large amounts of schema-less metadata, which is saved on the client (but refreshed incrementally as more web service calls are made). This metadata drives all the client side behavior about work items (what fields are in a work item type, the type of a field, which values are allowed in fields, the rules that run when they change, etc.) and it will take a long time and serious study to build the client behavior to bring a work item to life. Once you have a work item, sending it to the server for update via web services is easy.
It's a lot of work, but it's possible to do incrementally, for example, if you only need some VC features. The TEE team is working on making access from other platforms easier. Please contact Martin Woodward (martin.woodward#microsoft.com) if you have any questions or suggestions in this area.
There is a Java version of the TFS SDK that will run on Linux, Mac, and Windows. It is the SDK that Teamprise uses.
http://blogs.msdn.com/b/bharry/archive/2011/05/16/announcing-a-java-sdk-for-tfs.aspx
Coding directly against the TFS webservices is not supported (even though people have done it). MSFT could break the interface without letting you know in a service pack or other hotfix. Sometimes there aren't other options, but if the Java SDK works for you, I'd try to use that first.
There is good documentation now: https://www.visualstudio.com/integrate/get-started/rest/basics
Im my current project we need to interface with sharepoint to store and retrieve various documents.
This has previously been done by referencing the Microsoft.Sharepoint dlls directly and going from there. As I don't know a lot about sharepoint yet I have been doing some research.
Most of the examples I find actually refer to using the Sharepoint web services themselves (the various vti_bin ones shown in http://www.sharepointmonitor.com/2007/01/sharepoint-web-service/).
I cant seem to find the differences in approaches. This current project was written a few years ago so maybe the web services weren't available then?
I'm looking for a solution to add and retrieve data from sharepoint and also a little explanation as to the differences in using refernces vs the web service
Cheers
Referincing Microsoft.SharePoint.DLL is only supported on code that runs within SharePoint. It often does work on Projects that are not part of SharePoint but that are run on a SharePoint server, but that's a) unsupported and b) not all functions work. If your Applications runs outside of the SharePoint server, referencing Microsoft.SharePoint.dll won't work.
If you want to access SharePoint from an application outside of SharePoint, there's three ways:
Use the SharePoint Webservices, for example Lists.asmx
If your SharePoint site runs on SharePoint 2010, use one of the three Client Object Models (.net, Silverlight, JavaScript)
Develop some code that runs on the SharePoint Server and exposes the data through a Web Service. This only makes sense if you have to do something that's either complicated/painful to do entirely client side or if you really need full control over the web service.
Our company has a set of 3d modeling softwares written in c++ with qt based gui. We are planning to offer these applications to customers to try them from a web browser. I mean to say, we need to create web interfaces for native c++ codes. Please suggest me which technology, languages should be used. If possible please give some links to some white papers or case studies for this kind of projects. I am totally clue less :)
Ideally you would keep your c++ code on the server and use a mixture of HTML and Javascript on the browser. However since 3d modeling is so client centric you may have to run some c++ code directly in the browser.
There are a few options to look at:
Emscripten
Adobe Alchemy
Google Native Client
A Java Applet using NestedVM
Netscape plugin API
ActiveX
You could also run a few instances of your application on your server inside an XVnc session and let people use it through a VNC viewer applet. The simplest solution however is still to offer a downloadable demo of your application.
Have a look at Wt
Take a look at Native Client.
Soon you might be use WebGL to do 3D in the browser. But how long it will take for browsers to include it I do not know. But it might be good to look at it to not rule out using it in the future.
If creating everything again is too expensive, always you can create a distributed application:
One program running the main application in C++ and generating (for example) XML files.
A web application reading the XML files generated by the C++ application and translating them into the web application language (for example Adobe Flex).
Good luck!