Would it be possible to use the Office 2010 web apps with an ASP.NET application?
For example:
- For each user of my ASP.NET application there is a folder with Word documents on my server
- The ASP.NET application displays the available documents in a grid to the user
- When clicking on one of the documents in the grid, the Word document is loaded in an IFrame which contains the Office 2010 web apps Word interface and editing of the document can take place
- After editing, the document can be saved to the server, and the ASP.NET grid displays an updated status
Would such a scenario be possible? And what do you need, e.g. Sharepoint, Office 2010 licenses?
I think you will want to have a look at Sharepoint, because I think this is exactly what it does (plus many more things).
Windows Sharepoint Services (WSS) is a free add-on for windows 2003/2008 server systems and contains the base Sharepoint functionality. In addition there are the commercial products which extend WSS (MS Office Sharepoint Server or Sharepoint Portal Server or whatever they are called).
The Office Web Apps come with SharePoint 2010, but they are also used with SkyDrive. This indicates to me that what you are asking for is possible (Microsoft is doing it), but the software isn't bundled separately. Of course, I have no idea what MS had to do in order to integrate Office Web Apps with SkyDrive.
"Word document is loaded in an IFrame which contains the Office 2010 web apps Word interface"
you can not do that because of Office web Apps restriction. I ve tried open in IFrame, in sharepoint modal window. Unfortunately can not, only standart new window using.
Related
I'd like to implement somehow an endpoint on a .NET core WebAPI that allow a user to edit an Office document that he has beforehand downloaded and automatically opened in office from my WebAPI, and save it directly from the Office desktop client.
How could I do that ? One possibility is to DAV enable my API but I'm looking for a more lighter solution as I only want to manage opening and editing office document.
Currently my API sends the file and I'm planning to implement my web client to tells the system to open it in Office via Office URI Schema. I managed to open a word file in my Word Desktop app but I am stuck at this point and don't know how to edit and save it back.
Thanks for your help.
I am currently developing an application using Sharepoint 2010 Web services to access data from a Sharepoint server. Im using ListData.svc to get items of a particular list of documents saved in the SP server, and my aim is to be able to search through this list, including its documents contents. I have been researching through options, and have seen stuff like asmx, enterprise search API, query services, etc., but I am not quite sure if this would really crawl through the file contents.
Can you enlighten me on what web service to use to be able to search through a particular list of files-- all its properties and file contents? Similar to the search option in an actual Sharepoint site?
Thanks!
Id expect a quick google on "Sharepoint 2010 search api" to yield up https://msdn.microsoft.com/en-us/library/office/websvcspsearch(v=office.14).aspx which says "Search in Microsoft SharePoint Foundation 2010 exposes its search functionalities through the Query Web service. This allows you to access SharePoint Foundation Search results from client applications and Web applications outside of the context of a SharePoint site."
I guess if you read those docs, the solution will be in there.
Are there any free C# Asp.Net API's to host a server that has cloud capabilities.
All I really want is for users to be able to download Word Documents, The server marks it as locked. Then the user can edit and click "SAVE AS" And it saves it back to my server.
I dont want to use a third party server for this it.
The Microsoft .Net Framework is a free API that has cloud capabilities (ASP.Net).
You will have to implement the code to present the documents and lock them. And find a way to expose the server to the web.
Sounds like Sharepoint to me. A foundation version with the functionality you describe comes free with Small Business Server
We have an Enterprise application written in C# that we well to customers. The server runs in our data center and the customers connect via a windows application also written in C#. Pretty standard.
Management would like a dashboard added to our application. I was told to look into using sharepoint to somehow add a sharepoint dashboard to the main screen of our client application (winforms).
Is this possible? The client application would have to somehow show a web page from the sharepoint server which I guess is no problem using a html componenent. But I'm more worried about getting sharepoint to work with our existing data (sql server 2008).
I suggested just writing the dashboard ourselves and avoiding sharepoint. But management would like to add more 'Business Intelligence' to our application. I know that is the way of the future but I'm worried about the complexity of integration with sharepoint.
There are various options for integrating SharePoint into a windows forms application. The simplest is embedding a web browser control and point it to the page with the dashboard set up.
Alternatively you could use the SharePoint client object model (2)(make calls to the SharePoint server) and retrieve data (and potentially pages) from SharePoint to put into your dashboard.
I would recommend to management that we can display SharePoint through our current application, and we can demonstrate with a simple dashboard part (eg chart control) to demonstrate how we can make the dashboard integrate more naturally over time piece by piece. This would minimise risk by displaying from SharePoint, while being able to show the potential advantages of using the SharePoint data and creating a customised windows forms dashboard.
SharePoint does a good job of going either way with information via BCS, assuming you would want to show LOB data in a SharePoint deployment.
However, since you want to go the other way, the Client Object Model works well with this. Seeing as how it is a .NET application, I can site specific times where we have used the built in REST services to get information from lists in our enterprise SharePoint deployments.
Security will need to be addressed as well, so don't forget about that. If you have AD groups already set up for your enterprise application, you can most likely reuse some of those in SharePoint. If you don't, you will have to now manage how data will be secured. You may also end up getting prompted for a log in to SP which is never a good user experience.
Good luck!
I have a standard ASP.NET 2.0 website.
It has a webpage page.
I have a webpart in my Company.Web.dll that I display on my webpart page on my website.All is good!!!
I would like to use this same webpart in SharePoint 2007.
I have a "site definition" project in VS2008 using Extensions for SharePoint 1.2. I have tried various ways to add the webpart from an outside assembly to my site definition. I have been able to deploy the webpart (where it is added to the webpart list of a webpart page) but I have been unsuccessful at adding the it to a page.
My Glorious Failures:
Created a shell webpart to just display the existing web part, basically just using my part as a control.
Attempted to modify the X.webpart and X.xml files created by VS2008 when you create a new webpart.
Both result in the following error while adding the web part to the page:
Exception
Microsoft.SharePoint.WebPartPages.WebPartPageUserException:
Cannot import XXXX Web Part.
at Microsoft.SharePoint.WebPartPages.WebPartImporter.CreateWebPart(Boolean
clearConnections) at
Microsoft.SharePoint.WebPartPages.WebPartImporter.Import(SPWebPartManager
manager, XmlReader reader, Boolean
clearConnections, Uri webPartPageUri,
SPWeb spWeb) at
Microsoft.SharePoint.WebPartPages.WebPartImporter.Import(SPWebPartManager
manager, XmlReader reader, Boolean
clearConnections, SPWeb spWeb) at
Microsoft.SharePoint.WebPartPages.WebPartQuickAdd.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String
eventArgument)
Is there a special way I need to add my existing webpart to my site definition?
This sounds like a problem resolving the GUID at deployment time, as you can read about in this SO question.
To find the details of why the web part won't import, check the ULS logs. These are typically located at %CommonProgramFiles%\Microsoft Shared\web server extensions\12\LOGS. An entry will be logged here at the time you attempt to add the web part to the page. This should give you more detail.
My guess is that it is a code access security issue. Your web part must be strongly signed and needs a SafeControl entry in the web.config of the SharePoint web application. Apart from these things you should be able to just add it to the Global Assembly Cache to test if it works (best practice is to write a CAS policy file). See Deploying Web Parts in Windows SharePoint Services for more details.
I would try these steps before trying to integrate it as part of a site definition. Then at least you know the web part will actually run.
Also, VSeWSS is really designed for developing your web part using it from the very start. If you have the original source, you could try creating a new web part with VSeWSS and then replace with your custom code and update the .webpart and feature XML files. Then it should behave a little better. If you haven't committed to VSeWSS, try WSPBuilder as it's less painful.
ASP.NET webparts and Sharepoint Webparts are NOT the same. You should be able to use a ASPNET webpart within Sharepoint. See the following table:
ASP.NET 2.0 Web Part
For most business needs.
To distribute your Web Part to sites that run ASP.NET 2.0 or SharePoint sites.
When you want to reuse one or more Web Parts created for ASP.NET 2.0 sites on SharePoint sites.
To use data or functionality provided by Windows SharePoint Services 3.0. For example, you are creating a a Web Part that works with site or list data.
SharePoint-based Web Part
When you want to migrate a set of Web Parts using the SharePoint-based Web Part infrastructure to Windows SharePoint Services 3.0.
To create cross page connections.
To create connections between Web Parts that are outside of a Web Part zone.
To work with client-side connections (Web Part Page Services Component).
To use a data-caching infrastructure that allows caching to the content database.
For a Sharepoint webpart to work in a standard ASPNET application you would need to recreate your webparts in Visual Studio (as an ASPNET webpart) without the Sharepoint 2007 references for it to work correctly.
One nifty tool which I have used in the past is the SmartPart Worth checking out:
This lets you create a ASP.NET usercontrol (visually) in Visual Studio and then host this in Sharepoint. The smartpart acts as a wrapper wepart for your user control. Think of it like the page viewer webpart in Sharepoint except instead of it being HTML pages its ASP.NET UserControls.
You would need WSS 3.0, SharePoint MOSS or 2007 to use ASP.NET 2.0 WebParts. SharePoint 2003 or below and WSS 2.0 or below do not support ASP.NET WebParts.