I'm looking to take advantage of SharePoint's document management features for an intranet portal. Portal users, find SharePoint rather cumbersome so I would like to build most of the site in ASP.NET, and integrate SharePoint document libraries so that i don't have to create a document management system.
How can I do this?
In my honest opinion it sounds like you are trying to reinvent the wheel. If users are finding it cumbersome it is generally do to lack of understanding or incorrect implementation and training.
However if you do want to integrate into SharePoint, you can reference the full SharePoint API Library. It is .Net based and allows you to access any aspect of SharePoint in code. You need to reference the Microsoft.SharePoint assembly to access these classes. You will need to setup a development environment for this, since you can't develop for SharePoint without having it installed. The detailed documentation on the namespace starts here
From personal experience we had much more success implement a solid SharePoint structure, with training, and also building the SharePoint portal the same way we would have built a website. Users now insist on having applications in SharePoint.
Basically, you can set up and administer your document library (or libraries) through the standard SharePoint pages, but you build your own ASP.NET site for users which will access the information in the document library. This site will use either the SharePoint object model or the SharePoint web services to retrieve, manipulate and store documents in your document libraries.
Generally the rule is that if you are deploying your ASP.NET site onto the same server as your SharePoint instance, then use the Object Model; if you are deploying to a separate web server, use the Web Services.
Some of the common issues for SharePoint development, and how to avoid them can be found here:
http://msdn.microsoft.com/en-us/library/bb687949.aspx
The “Working with Folders and Lists” section will be particularly relevant to what you are doing.
Use an IFrame :)
Seriously.. you'll have to work within the context of SharePoint or you will find yourself rebuilding SharePoint. This excludes building it as a regular ASP.NET app. But it is not that far off.
Why not adapt the way SharePoint works to how your users like to work? It was made to be changed and appended.. within limits.
Related
OrchardCMS, Umbraco and DotNetNuke are CMSes in .Net galaxy. They work as stand alone applications well. Suppose I have a requirement that need CMS features in an another ASP.NET MVC application. I do not like to implement CMS again in the application. Rather I like to use current CMSes as a component of application.
Is it possible at all to use for example OrhcardCMS as a component of my MVC application? It is ideal to have relations between CMS and application itself, for example I can load entities from CMS, update them etc.
I know there are integration techniques in .Net. For example ASP.NET Identity integrates with ASP.NET applications in core level, but view (CSHTMLs) must be copied and customized in most cases. Or Hangfire and ELMAH that integrates with an application without need to copy view (cshtml, html, css) to the target application. Indeed it is good to know that integration methods are available regarding plugging CMSes into ASP.NET applications.
I can tell you more about Umbraco as I don't know other CMS as much as this one. There is a whole course / training for those who want to integrate their apps with Umbraco: https://umbraco.com/products-and-support/training/umbraco-application-integration/. So yes, it's possible and it's even suggested way from my perspective to use already done piece of software rather than building the wheel once again.
Umbraco is an ASP.NET MVC application. You can use Umbraco components, backoffice, membership and everything else CMSish delivered out of box and still you're able to write and use your business logic, controllers and everything else what you've created inside your ASP.NET MVC / C# app. Still, it's an ASP.NET app, so you can use anything what you want from the .NET world. We're using ELMAH.io for example to take care of logging and keeping the errors in the cloud. We're also using a ton of 3rd party, both open-source and commercial tools and softwares to do multiple things around our web components. Umbraco is not blocking us from using them or anything else. I like to consider Umbraco as a framework or library helping us to deal with content editing and giving us a massive number of opportunities to offer for our clients or editors.
Speaking for OrchardCMS, there are some questions touching this subject already, see
Reusing Orchard's Core to build another extensibility framework
Extracting a Module from Orchard
If it's possible for you then try to setup Orchard as the base system and move your MVC application in a module. This will be much easier than trying to cut out peaces of Orchard. In return you get amazing possibilites when running Orchard as the underlying framework, e.g. Localization, Modules, Themes, the whole user / role management etc.
OrchardCMS 2 is currently developed towards single components that can be reused in any application but it's far from finished yet.
I'm looking at the differences between a Web Site and a Web Application on MSDN, and am drawn to the features of a Web Site because I am tasked with devising an architecture in which customers can heavily customize the application we deliver. It seems this feature of web sites would be useful:
You want to be able to update individual files in production by just
copying new versions to the production server, or by editing the files
directly on the production server.
However, I'm also drawn to the MVC architecture because it has built in features for minifying scripts that are delivered to the client. I also kind of like the idea of breaking up the architecture into clean pieces since this is a very large data model we have.
But from what I can tell, these sets of features appear to be mutually exclusive. Is that true? I can't readily figure out how to create an MVC application in which custom views could be dropped in as pure source files, and be able to run, nor can I figure out how to take advantage of any MVC framework when creating a "Web Site" project. Am I missing something or do I have to pick my poison?
Take a look at ASP.NET templates in VS2013. You can create an app with both MVC and WebForms. This will probably give you a good combination of what you need. By default, view files are not compiled, so you'll always be able to publish new files without doing a full push if you want. In fact, VS2012 even allows you to publish select files or folders.
The choice between web site and web app to be is very simple. If you are creating a mostly static app, choose "web site". If you are creating an app that has even a decent amount of dynamic capabilities, choose "web app". Web Sites are not really designed to be dynamic, so the more dynamic you do in that setting, the more of a headache it will be to properly maintain it as the architecture just isn't where it would need to be.
What I would suggest is to spin both of them up and try out some scenarios that you are interested and see what works and what doesn't. Really think about how users will actually want to customize the app. Will they want to copy and paste files to production or would they rather request features and have them built properly? Or maybe they want to work with a workflow instead?
So make realistic business requirements, prototype and then decide. But based on what I'm hearing you want a WebApp and probably one that does MVC and WebForms.
Now everything ONE ASP.Net. You will be creating a WebForm, MVC, Webpages using ASP.Net platform.
Check this video about new features in VS 2013
Not sure you can create website in ASP.Net 4.5.
From my experience, I would go with WebApplication based project, where managing namespace and other stuffs are easy. In website its hard to get the standard name for the classes(randome) generated.
Go with MVC web application.
We have many custom built web applications (both external & internal) written in Classic ASP and ASP.NET 2.0 technologies. Internal users can upload files to these websites, which can then be viewed by External Users. In some cases, external users can upload documents as well.
Screenshot #1 gives a brief idea about the existing architecture.
Internal users upload documents to custom web applications. These documents are stored in a folder structure defined under the web application.
Meta data and user permissions like who can access the documents are stored in SQL Server database.
The same set of documents that are being uploaded to custom web applications also exist in SharePoint. However, the custom web applications are unaware of SharePoint. So, users have to download them from SharePoint and then Upload it to the custom web applications. We are currently using SharePoint 2010.
External users can also upload documents to the custom web applications. The meta data and user permissions of the document are saved into database based on the user who is uploading the document.
Screenshot #1:
Screenshot #2 shows the architecture that I am trying to achieve. I have done very little SharePoint development. Mostly, I have used the SharePoint web services to retrieve some list content but nothing more than that. Our future Custom Web Applications might be written using ASP.NET MVC. Please find the questions after the screenshot.
Screenshot #2:
Here are my questions:
I would like to have internal users continue to upload and maintain their documents in SharePoint. User security model is already defined in the SQL Server database. This security permissions should be available in the SharePoint document properties so users can choose who can view the document from the custom web applications. How can I achieve this? Should I have to copy the SQL Server user permissions info to SharePoint?
I believe that SharePoint Web Services or Business Connectivity Services (BCS) can help in retrieving the document and its related info from SharePoint. Which one of these would better suit this scenario?
Custom web app should display only the committed versions of the documents. If a user has checked out a document in SharePoint to make any changes, that checked out version of the document should not be visible to External users. Is that possible?
Has anyone tried this approach? Are there any pitfalls with this model? Are there any performance concerns with this design?
Will this design be of any hindrance if I rewrite our existing applications using ASP.NET MVC?
Is it possible to make use of SharePoint search feature within the custom web application (ASP.NET Web Forms / ASP.NET MVC)? In other words, can I send search criteria from custom web app and have SharePoint do the search and return the results back to custom web app?
I really appreciate your inputs.
Thanks in advance.
Question 1
Hard to say without having more details. So I'm going to assume that you currently use Active Directory for your authentication store. So this means that your SQL Server defines a list of roles and then has assigned memberships to these roles. I'm going to assume that your assigned membership is to AD users or groups. If this is true then I think your on the right path to push your permissions from SQL Server into SharePoint. SharePoint's API will accommodate what you need to do, however SharePoint has no built into mechanism for syncing your permission changes so that means you end up writing a whole lot of plumbing code. I would recommend that you research products that can handle the synchronization for you. Microsoft MIIS (I believe it is called Forefront Identity Management now) offer a set of architecture patterns that you should investigate.
Question 2
SharePoint Web Services or the SharePoint Client Access Services should work fine. I would highly recommend that use a proxy pattern to isolate your application from SharePoint calls (so you can isolate your application from SharePoint upgrades and potential content management server changes).
Question 3
Yes, that is possible. If you are using the publishing features of SharePoint Server (NOT SharePoint Foundation) you will have an easy way of identifying the current published version. Otherwise the service account you query with should be setup so it can only read published versions then SharePoint will automatically trim your query.
Question 4
I have not personally tried this design, but I really like the concept of creating a content management domain and then putting an abstract service layer on top of it. Will you have scale problems, depends on how you configure SharePoint and your applications. You can do it right or wrong. An depth answer between the two cannot be covered here. My one piece of advice is to make sure you plan for caching in your service interfaces (cache, cache, cache).
Question 5
Not if you implement it as a Service Layer. You would just use a repository pattern to call the service and return back entities for your model.
Question 6
Yes, Search is exposed via an API so it can be wrapped in a service layer too.
Good luck and feel free to contact me directly for more in depth discussion.
I'm new to developing in SharePoint and would like some tips please. I want to develop a WebPart. I understand that I effectively need to do this on a machine with SharePoint Server installed and create the web part as an ASP control. Once the control is created, how do I link it into SharePoint?
I would recommend you to take a look at the WSP Builder extensions for Visual Studio. It will simplify the development and deployment process for you, since it contains both templates for web parts, features and it will also package it up in a WSP solution for you.
I would read though this:
http://msdn.microsoft.com/en-us/library/ms452873.aspx
It will answer a lot of your questions about creating a web part, deploying etc.
If you're using the Microsoft Provided WebPart Visual Studio template...it will automatically be deployed to your site when you build it.
If you need to deploy to a test/production environment, you need to create a SharePoint Feature and then deploy the Feature to the server.
http://www.allaboutmoss.com/index.php/2010/03/22/hello-world-sharepoint-webpart-for-beginners/ helps you to create simple webpart and shows how it deploy in server.
You are able to build Web Parts in a number of different ways, through Visual Studio .NET using either the SharePoint Web Part Namespace or the normal ASP.NET Web Part Namespace further you are able to build Web Parts in SharePoint Designer using a combination of different technologies, such as XML Web Services.
XML Web Services will allow you to hook directly into SharePoint using SharePoint's Native Web Services, you can then create a Data View Web Part which will enable you to view, collate, filter and group List Items. This, of course, will also allow you to mingle normal HTML as well as XSLT syntax, allowing you to build logic into the Web Part.
The good thing about doing it this way is there is no "real' coding, i.e. no Code Behind page etc as there would normally be in ASP.NET. This also allows you keep things more or less SharePoint Centric, which is important because you may or may not have access to Central Admin or SSP nor indeed the Server itself, the 12 hive or the GAC.
How you decide to develop Web Parts should include thinking about all of the above, you may have a very restricted development environment. Further, you can also use Namespaces provided directly from GAC assemblies provided by Sharepoint, you may either need access to a development environment which has a MOSS or WSS Server on it or the PIA's or Assemblies from a MOSS/WSS Server.
I am a software developer, however, it is important for me to develop applications which are as SharePoint centric as they can be, which is why I decided to develop my Web Parts in SharePoint Designer. However, there have been times when using full VS.NET is the way to go, I would suggest you look at SharePoint Designer first, get a feel for the interface, XML Web Services, XSLT and HTML once you have created a SharePoint Designer Web Part and Provided this Web Part exists within a Web Part Zone, you can export the Web Part and reimport it into any number of Site Collections.
I must add that the above relates to SharePoint Lists and Libraries but it gives you a grounding to understand how it all fits together. it helped me understand more and made development of more coded Web Parts easier, It may not suit your individual requirements, SharePoint is a huge environment offering many paths.
Hope this Helps you out, search for SharePoint Designer... at least as a starting point.
Cheers
Is there any way that I can use SharePoint document library and document sharing functionality from an ASP.NET page?
There's 3 ways you can have your standalone ASP.NET (standalone meaning not integrated into sharepoint) interact with sharepoint.
1 using the SharePoint object model (sharepoint APi dll's). This way allows you to control every part of how your ASP.NET site interacts with SharePoint (document security etc.) The major drawback is that you ASP.NET site needs to be running on the SAME SERVER as SharePoint (or if sharepoint is used in a farm any machine that is running sharepoint in that farm). Simply including the SharePoint DLL's will NOT work when run on any other machine (even when that machine also has sharepoint installed but is not part of the farm you want to communicate with!)
2 Web Services. These OOTB services can be used from anywhere but are not very extensive functionality wise. They allow you to perform a lot of actions and retrieve a lot of data, but when it comes to more finegrained control they just don't cut it. It might be enough for what you want to do though.
3 Use web services and create your own webservice that is deployed to sharepoint for any tasks not doable with the OOTB services. This requires access to the sharepoint machine in the form of deploying custom code / assemblies though.
I assume that your asp.net application is running on another server because if thats not the case the it would probably be easiest to just use the SharePoint functionality directly and maybe include your app into SharePoint
SharePoint exposes a lot of it's functionality through Web Services, so you can get, add, delete and update information through these.
You can include any SharePoint page into a page in another portal using an IFrame. The main issue there is the fact that you will get the MOSS navigation in that IFrame, which typically is not desired. To overcome that, you can create a special MOSS page that hides all those elements and show just the element you want to expose. To accomplish that, you can create a “minimal” master page and a simple layout with a single web part zone.