I am used to building java web applications.
I am used to MCV.
As I learn how to build a Sharepoint site, is it ok to think of building Sharepoint sites similarly, particulary where there is business logic layer, that, for instance, would grab data from various DBs, do some logic, then go to a certain page?
SharePoint and MVC do not play well together, not in a supported way at least. This isn't going to change for 2010 either. It's an ASP.Net Web Forms app, and so acts accordingly.
There is a Open Source Project for SharePoint MVC but you need to understand the plataform first, with some SharePoint for Developers tutorials.
Related
We have an ASP.NET website that we use internally to do some project tracking and various work. We would like to integrate some pieces of it to co-exist with Sharepoint2007 WSS.
Basically what we would really need to do is be able to add items to a list in one of the Sharepoint sites.
I'm not sure where to begin. I've looked online a bit but it seems overly complicated. Is there a quick start guide somewhere that can get me rolling with ease?
The SharePoint Web Services would be a logical place to start. In my opinion this would be the easiest way to build interaction between ASP.NET and SharePoint.
A list of available web services can be found on MSDN.
If adding items to a list is the primary goal, then check out the UpdateListItems method of the Lists web service.
With the scope narrowed to Web Services, you can certainly find tutorials/references online. However, this InfoQ post by Trent Swanson is a decent introduction to SP web services. Note that they recommend generating .NET types using XSD files; in practice, for simple projects I have simply parsed the XML myself using LINQ. You can make it as easy or complex as you like, I suppose.
This is an architectural question.
We are in the process of building a document management site with basic workflow which needs to be external facing.The external facing application needs to be branded and should have the capability to upload and download documents and also support versioning.We have decided to use WSS 3.0 as the collaboration tool as it has all the features we need.We are planning to support multiple clients with custom branding for each client.
My question is should we expose WSS to the client for external facing or build a standard ASP.NET application using WSS in the application tier and let the ASP.NET app interact with WSS using the WSS API/Web service.This makes it easy to customize the ASP.NET application without having to make any changes to the WSS.The internal users doesnt need any branding and hence could go to the internal facing WSS site to do workflow activities. Building features and getting to brand has been a challenge since I started WSS development.
Please let me know your thoughts.
SharePoint is big. Really big. As a result, if you plan to develop a home-brewed middle layer between your customers and SharePoint, be prepared to do a lot of work unless you plan only to expose a tiny piece of the SharePoint interface.
I recommend exposing WSS, and building your application within, instead of adjacent to, the WSS framework by creating Web Parts, pages, and lists that meet the requirements SharePoint alone cannot. This should reduce your workload to something manageable.
Take a look at tools such as VSeWSS or WSPBuilder to ease your WSS 3.0 development (should you use Visual Studio), and take advantage of SharePoint Designer where it is appropriate.
If you don't know a lot about SharePoint, creating and exposing a UI is going to be difficult. Can you do it? Absolutely. Should you do it? That depends on your requirements, and your level of expertise with SharePoint. In my opinion, the easiest path would be to create an ASP.NET application and have that interface with SharePoint, but I spend 90% of my day working with ASP.NET and only do SharePoint development about once a year.
In my experience, if you have to ask whether or not you should build a new product etc. with some tool, the answer is generally know. If I can't answer it myself with maybe some looking around on the tool, I try not to use it on a major project, because that means, that I don't know it well enough to get myself out of bind when something unexpected arises.
If you do a custom coat over WSS underneath, you are essentially writing code that already comes with the platform, especially with SharePoint. I assume that price is a factor in your decision making or you would not use WSS alone. In that case it can be tempting to leverage WSS as a code layer, but I would expect that it would be extremely difficult to make that work smoothly.
Depending on your business model I would look at what hosted SharePoint solutions can do, especially if you can host a custom SharePoint site definition on their platform.
It would take a very strong IP or financial requirement to make me consider wrapping asp.net over top of WSS.
I have worked with a solution that does that and it does work for our externally facing site, but it is a maintenance 'mare.
We currently have a fully developed web forms application, basically its like WordPress using .net for multiple users to publish content. It does more than that but thats the simplest way to describe it. Our "webmasters" (I work in the gov) want everything put inside of SharePoint. We currently have SharePoint 2007. I have no experience developing within SharePoint so I don't know much about it.
My question is how do you decide when to develop your application in SharePoint and when to develop outside of it.
It depends on several things.
Is there any reason to use SharePoint features (lists for data storage, document libraries with versioning, groups for security, etc.) in your application? If you're just hosting ASP.NET pages within SharePoint but aren't using any of its features, it's not really worth the hassle.
However, if you would be adding the application to an existing SharePoint site, it might still be a good idea. Organizing everything in one place might be more convenient for users than setting up a separate web application.
If it is a requirement to re-architect your application to work with SharePoint, that is one very big reason to develop with SharePoint. Beyond that, the people influencing your architecture decisions may have good reasons of their own.
SharePoint provides security management, search and navigation to name a few relevant pieces to your web puzzle. If you are already creating dynamic web applications in .Net, a lot of what you've learned in the process will apply, but you have some learning to do.
Your orginization is not the only one moving most web applications to SharePoint. If you don't learn it now, you risk getting behind the curve.
You could also just 'show' your existing applications inside of a SharePoint web part (Page Viewer?). That way, your application remains the same, and it is 'shown' inside the SharePoint environment. This is somewhat a hokey solution, but in your particular circumstance, it could be viable considering development time, learning time, and control.
We've been asked to create a web application. One part of the specification is that in future, it can be integrated into Sharepoint. The last version of this app was written in PHP and "integrated" by means of an iframe embedded into Sharepoint; not ideal.
I'm looking to understand the use of Sharepoint in this context. I believe that you can write Sharepoint Applications which are more "native" to Sharepoint than the rough-and-ready iframe approach I discussed before. How easy is it to take a standard ASP.NET MVC application and fully integrate it into Sharepoint?
Does anyone have any thoughts, experiences, or resources on this matter?
I think the first question is what kind of integration with SharePoint are you trying to accomplish? The simplest is to use the Page Viewer webpart (i.e. iframe) method. You can also write custom webparts that show data from your custom application. That's a form of integration. The ultimate form of integration, of course, is to make your application run inside of SharePoint. That leads to my next point.
SharePoint (as of version 2007) is essentially a giant ASP.NET framework. So you can theoretically use it to host any ASP.NET web application. I have actually done it before and it works. However, that was a plain old ASP.NET webforms application (not MVC). If this is what you are trying to do, you definitely would need to rewrite your php application in ASP.NET.
In Sharepoint there is a Page Viewer webpart using which you can load a different url. This way you can easily "integrate" your application to sharepoint site ;-)
But if you are really looking at Re Engineering the application in SharePoint then its a different story. You have to study the current application and then develop it in SharePoint.
This fellow has an approach to writing PHP for SharePoint. A key statement:
There are two big tricks – getting the
XML right and using NTLM
authentication.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I have been asked to develop some usercontrols in ASP.NET that will at a later point be pulled into a SharePoint site as web parts. I am new to SharePoint and will not have access to a SharePoint server during the time I need to prototype these parts.
Does anyone know of any reasons that this approach will not work?
If this approach is not recommended, what would other options be?
Any suggestions on a resource/tutorial on what to consider when developing an ASP.NET web part with SharePoint in mind?
Thanks
Edit: 12/31/2008
I finally marked an answer to this one. It took me a while to realize that going the SharePoint route right away, though painful at first, is the best way to go about it. The free VPC image makes getting set up to develop relatively painless.
While you can, as I did, develop web parts in ASP.NET without SharePoint, when it comes to developing and deploying SharePoint applications you haven't learned a thing, only pushed the learning curve off into a time when you think you are done, (and have probably informed stakeholders to that effect). To delay the SharePoint learning curve doesn't do you or your project any favors, and your final product will better for the expertise you gain along the way.
ASP.NET web parts work in SharePoint the same as they work in ASP.NET. That's the route I would take (custom control that derives from the ASP.NET Web Part class). This will alleviate any requirement to actually develop on a SharePoint server.
The only issue you are going to encounter is that you will not be able to take advantage of the SharePoint framework. If you are doing anything advanced in SharePoint this is a big deal. However, SharePoint is ASP.NET plus some additional functionality, so anything you can develop using the System.Web.UI.WebControls.WebPart class should work great in SharePoint.
Some considerations that will help ease your pain as you go from pure ASP.NET to SharePoint:
If you can put everything inside of a single assembly, deployment will be easier
try to put everything you need into the DLL's that are deployed to SharePoint
use assembly resources to embed JS, CSS, and image files if needed
Strong name the assembly you are building
Most SharePoint deployments end up in the GAC and a strong name will be required
Here is a relevant blog post; Developing Basic Web Parts in SharePoint 2007
If it's a very short-term thing, Microsoft has a time-limited WSS evaluation VPC image:
WSS3 SP1 Developer Evaluation VPC image
That will get you started if you don't have time/resources to set up your own VPC image right now.
I guess the easiest way is to use the SmartPart for SharePoint from CodePlex. The project description says "The SharePoint web part which can host any ASP.NET web user control. Create your web parts without writing code!", which I guess is exactly what you want to do.
Setting up my machine to develop for Sharepoint took me a couple of days.
See http://weblogs.asp.net/erobillard/archive/2007/02/23/build-a-sharepoint-development-machine.aspx
Build and test the control as you would for a typical .net web site.
Solution 1 = the controls
Solution 2 = dummy website to host the controls.
Deployment on Sharepoint:
You'll need to sign the controls.
Drop the signed DLL into the GAC on the sharepoint server (Windows/assembly)
Mark the control as safe in the virtual server root web.config on the sharepoint site.
i.e.
<SafeControl Assembly="MyControl, Version=1.0.0.0, Culture=neutral, PublicKeyToken=975cc42deafbee31" Namespace="MyNamespace" TypeName="*" Safe="True" AllowRemoteDesigner="True" />
Register the component in your sharepoint page:
<%# Register Namespace="MyNamespace" Assembly="MyControl, Version=1.0.0.0, Culture=Neutral, PublicKeyToken=975cc42deafbee31" TagPrefix="XXXX" %>
Use the control:
<XXXX:ClassName runat="server" Field1="Value1" Field2="Value2" ....></XXXX:Classname>
If you need to replace the control using the same version number, then you'll need to recycle the app pool to reload.
If you don't need to do anything SharePoint-specific (ie accessing lists, other webparts, etc) then you can build your webpart just like a regular webpart (derived from System.Web.UI.WebControls.WebParts.WebPart class) and it will work when added to a SharePoint site.
you need to have access to a sharepoint server because you can't simulate your webpart without it, you have to deploy it to your sharepoint site to test if it's working. debugging would also be a pain. or you can use SmartPart, it's a webpart that acts like a wrapper for your user controls to display in a sharepoint site.
You do not need SharePoint to develop WebParts. You can develop webparts by inheriting from the System.Web.UI.WebControls.WebParts. And this is the preferable way of creating web parts unless you want the following features like
* Connections between web parts that are outside of a Web Part zone
* Cross page connections
* A data caching infrastructure that allows caching to the content database
* Client-side connections (Web Part Page Services Component)
In which case you need to develop webparts by inheriting from Microsoft.SharePoint.WebPartpages.WebPart. You can find more useful info here
Is there any particular reason why your user controls must be deployed as web parts? It is perfectly feasible to deploy user controls directly to Sharepoint sites either through the CONTROLTEMPLATES folder in the 12 hive or to a location in the web app virtual directory, which you can then reference from web pages using Sharepoint Designer.
If however the web part requirement is crucial then I recommend Smartpart for Sharepoint as already mentioned.
Actually, Web Parts should always be deployed to the sharepoint's bin folder due to their 'abusive' nature. Always deploy web parts to the bin if possible and write your own CAS and include it in your manifest.