So at work we are currently using SharePoint 2010 for all our sites. But something came up that we need to have a site up that is not SharePoint but an ASP.NET application. Is it possible to host an asp.net site on the same server that is hosting all our SharePoint Sites?
Thanks in advance. and please help in a tight deadline thanks:)
Yes, generally this is possible. If you ASP.NET app runs within a separate IIS web site, then there should be no issues. What you need to pay attention to are possible conflicts between DLLs in GAC and you ASP.NET app's dependencies. For example, if one of your SharePoint sites uses a library X.dll as part of a customization and it is (unfortunatelly) deployed into GAC and the ASP.NET app relies on a slightly different version of the same X.dll, that may cause a conflict.
You can even incorporate plain ASP.NET applications into SharePoint web sites; however, in such case you may run into some issues depending on the app's internals (again DLL conflicts, authentication conflicts etc.).
Will we be able to add .NET code blocks to a page in SharePoint 365 - the cloud version of SharePoint? If so, how do we allow code blocks in the web.config?
Will we be able to use SharePoint designer to customize forms and create dataviews with external datasources?
Can we have asp.net codebehind files and class references? (I suspect not)
.NET code blocks (server-side scripts) are not supported in Office 365. You should build your ASPX page purely from controls and web parts, which would contain the code. Solutions for the SharePoint Online share their restrictions with sandboxed solutions for SharePoint 2010. The solution scope is a site collection; not a web application and thus you cannot access the web.config. However, you may not need to; you're bound only to a single site collection and the most usual task - adding SafeControls - is supported, although the SharePoint engine does not use web.config to maintain them. You can see an example of deploying a web part.
You can use the Designer to customize pages, forms and views. External data sources (entity types) - BCS - were added to SharePoint Online by the end of the last year. I haven't checked what connector types are supported; I presume SQL and WS sources, at least.
You cannot have the code-behind in ASPX pages. There is no ASP.NET compilation of pages and user controls available; that's why you have to compose your pages of coded controls and web parts only. However, there is a trick to circumvent this - the Visual Web Part. The original visual web part could not be used in a sandboxed solution because it relied on the ASP.NET compilation. There is a template available in Visual Studio 2010 SharePoint Power Tools that packages pre-compiled code to the solution and is friendly to the sandbox.
You can develop and test your sandboxed solutions on your local SharePoint 2010 prior deploying them to the SharePoint Online. Although I was surprised that deployng a solution to the SharePoint Online was kind of faster than to my local farm :-) MSVS makes the development really comfortable.
--- Ferda
Not being a .NET developer, here is my limited knowledge. Office 365 is a multi-tenant implementation of SharePoint and you you should have the following capabilities:
upload code blocks as sandboxed solutions
ability to customize forms and data views with SharePoint Designer
Note that Office 365 offers 30 day trials that would allow you to test drive it. Let me know if you need more details as there are a couple caveats to be aware of when you start a trial.
This question relates to how to implement what Mr Prantl suggested.
Where to write C# code for office365 sharepoint site
Hope this helps.
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.
i have a wss 3.0 site up and running using forms based authentication. Is there a way to upload multiple files (basically copy and paste a folder containing files)?
also, when i try to access the site using designer 2007, i can't access the site and it asks me to install sharepoint services or frontpage extensions. how can i modify the site using designer?
I know that in designer that the functionality exists to copy/paste a folder.
Thank you!
Regarding your first question, see this on Stack Overflow. Essentially, it's by design and Microsoft don't give you that functionality. You could try turning on Client Integration but I don't know if it will work. If you need an alternative, searching around I found UploadZen which seems to support multiple uploads with FBA.
Are you also using forms auth with SharePoint Designer? The bottom of this blog post from Mike Hatch has information that might help you.
Try out installing the SP2 for the SharePoint 2007 and the office Application. In the Office application they have solved may of the issue that were part of FBA enabled sites. Please refer to this for more information.
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.