We have some asp.net pages that include the asp.net membership user controls for forms based authentication and would like to make use of these in a SharePoint MOSS environment.
Can anyone suggest the best place to deploy these and the best method for deployment, I was hoping to use solution packages to deploy them to the root of the site.
Appreciate any feedback
A good technique I've used previously is to make a copy of the standard SharePoint login page and make changes to that. There is an article by Damon Armstrong that describes how to do this. His article is good apart from making a copy of the _layouts folder which I believe is overkill. You can just put your amended copy of login.aspx and login.master in its own folder under LAYOUTS in the "12 Hive". Then configure ASP.NET to use these custom files with this directive in the FBA site's web.config:
<system.web>
<authentication mode="Forms">
<forms loginUrl="/_layouts/CustomFBA/login.aspx" />
</authentication>
</system.web>
As the custom pages are going under the Layouts folder they should be trivial to add to a solution file.
This sounds to me like a good candidate for an Application Page, deployed to the 12\TEMPLATE\LAYOUTS folder. MSDN has a Visual How-To here: Creating an Application Page in Windows SharePoint Services 3.0. At a minimum you would need to set your master page to ~/_layouts/application.master and deploy the assembly with your WSP.
Related
I'm creating a sharepoint project with custom webpart that includes custom user controls.
Is there any way to include a web.config file in this project?
Some of the references I'm including use the web.config file.
Thanks
You can use Property bags for storing configuration settings. Take a look on this post.
You have several options to work with the Property Bags:
SharePoint Designer
PowerShell
Custom code
Codeplex solutions (as SharePoint Property Bag Settings, that provides a farm solution to work with the Property Bag using the SharePoint UI).
So, I believe there is no way.
You have to include your entries in the SharePoint web.config file.
The correct way is not to use a web.config, but if you really need it then use the SharePoint web.config.
I am new to SharePoint, I am using SP 2010. I am asp.net developer but I don't understand if I have web.config under 80, so what are those web.config files under 14 folder, can you briefly discuss it?
I found two so far, There is one under 14\Templates\Layouts and under 14\CONFIG
Thanks
SharePoint development is similar to ASP.NET development but there are some major differences you need to be aware of. One is the use of Web.config to store application settings.
I wrote a blog post with links to several resources to help new SharePoint developers get started: Getting Started with SharePoint 2010 Development–Links and Resources
I suggest you start by watching the SharePoint for ASP.NET Developers talk to get an idea of the SharePoint architecture and development/deployment model.
You will find a lot more in 14 hive :) They are there because they are web.config files for different parts of the entire sharepoint application pages. For example the one in "14\layouts\" is for general application pages, site settings, regional settings, ... for instance. the one in the 14\layouts\admin is for centeral administration pages.
I've been trying to follow the information from:
Long URL clipped to stop breaking the page
and
http://msdn.microsoft.com/en-us/library/ms415817.aspx
Which more or less have the same instructions. I've been copying the .dll file from the build over to the BIN directory of the Sharepoint site.
When I click the Web Part Gallery and hit new, both articles say that the web part should show up in the list.
I have tried every possible way that I can think, but my web part will not show up in that list. Is there a step that I missed somewhere? Are there permissions that I should be thinking about? How exactly does Sharepoint recognize that there is a new web part. Is it simply from having the assembly placed in the BIN directory, or is it from adding the control in the safe list of web.config?
I've added it to the safe controls list. I've tried every different combination that I could think of, but nothing has worked.
Do I need to rename the .DLL assembly to something else?
For the life of me I cannot figure this out.
I believe the minimum you need to have a WP show up in the "New" Part of the webPart Catalog, you need the dll in the "bin" folder (bin in the web dir, not the 12 hive :)) or in the GAC and a safe control entry. I would verify the Safe control entry:
Assembly = name of dll
NameSpace = well... The NameSpace where your WebPart class resides
TypeName = the name of your webPart class
You can wildcard the NameSpace and TypeName just to be sure you are getting there:
... Namespace="*" TypeName="*" ...
I would also recommend signing the assembly and putting in a PublicKeyToken=...
Also, try setting the trust level to WSS_Medium or Full.
If this doesn't work, you can try adding a .webpart file to the wpCatalog folder in your web dir.
Edit: Clarification
This has to be a mismatch between your assembly and what has been entered into web.config for the safecontrol entry.
The safecontrol entry is case sensitive - and the smallest of errors will stop is from showing on the 'New' listing of the web part gallery.
Also make sure you are editing the correct web.config! :-) Another common gotcha is that your web part class has to be public.
Hope this helps
Nick Swan
Have you tried using the WPPackager tool from Microsoft? I haven't touched SharePoint since v2003, and I know there was a handy tool for WP deployment for that platform. I'd offer a link to it, but 1) I can't remember its name, and 2) I'm not sure if it is a valid installation route for your version of SharePoint.
Wow, you have me stumped ... I would try deploying some other 3rd party "free" web parts manually and see if you can get those to show up. This site has a few:
http://www.sharepointblogs.com/mkruger/archive/2007/06/26/free-sharepoint-web-parts-3rd-party.aspx
Have you made sure that you set: [assembly: AllowPartiallyTrustedCallers]
in your AssemblyInfo file?
I am amazed no one else has chimed in on this. I guess next step would be to try to deploy it as a feature/solution.
Is this a simple hello world wp or are you doing something more?
To be honest, I am beginning to believe that it is your wss/moss configuration/settings that is hampering your efforts at the moment. Have you ever successfully deployed a WP to your farm? ... Is this a VPC dev farm or production?
I've been creating a few web parts over the past 2 weeks, but I have not used the "New Web Parts" section of the Web Part Gallery. Instead, I create a .dwp file (e.g. MyWebPart.dwp), which is more or less an XML file describing the web part, and I manually import it into the gallery.
The format for my .dwp files generally looks like this:
<?xml version="1.0" encoding="utf-8"?>
<WebPart xmlns="http://schemas.microsoft.com/WebPart/v2" >
<Title>My Sample Web Part</Title>
<Description>This web part displays "Hello World" on the page.</Description>
<Assembly>My.Assembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3ed03eac7f647a61</Assembly>
<TypeName>My.Assembly.MyWebPartClassName</TypeName>
<!-- Specify initial values for any additional base class or custom properties here. -->
</WebPart>
This of course assumes that you've added this assembly as a "Safe Control". After you compile your assembly and move it into the bin/GAC for your SharePoint machine, go back to the web part gallery, click "Upload", and upload your .dwp file. You'll have to specify a few properties after uploading it.
Assuming your web part exists in your .dll, then you should see it added to the gallery list, and you can preview it or add it to a page at that point.
We have a SharePoint farm with multiple WFEs. A new application requires us to write some custom code to the web.config during deployment. What is the best way modify the the web.config file during deployment, ensuring that each WFE in the farm get updated?
I'm assuming you'll be deploying your code via a WSP; if not, using a tool like WSPBuilder is a great starting place that allows you to get rolling without forcing you to learn all of the intricate details of solution package construction.
You should leverage the SPWebConfigModification type from within a custom SPFeatureReceiver. Normally, the FeatureActivated method of the SPFeatureReceiver would be coded to write the changes out to the web.config files impacted by your activation. Those same changes would then be retracted in the FeatureDeactivating method.
The nice thing about the SPWebConfigModification type is that SharePoint takes care of determining which web.config files should be modified -- across servers and across extended web apps.
I hope this helps!
As part of your deployment, use the SPWebConfigModification class to add/remove entries from web.config. SharePoint will manage updating the WFEs for you if you use this.
A blog post entitled, Modify the web.config file in SharePoint using SPWebConfigModification, is a great summation of the gotchas involved and contains links to other helpful resources.
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.