Is it Possible to use Visual Studio/C# to develop for SharePoint 2007 without Deploying DLL to Hive

If a customer does not allow installation of a .dll into their SharePoint 2007 hive (or the GAC), is there any way to create webparts, etc. with Visual Studio that will not require deployment of the .dll(s) into the hive (or the GAC)? If not, is there another way to use Visual Studio and/or C# with the SharePoint namespace functionality in a similar fashion even if not quite in the standard way? This customer isn't going to allow us to install anything on the box beyond the pages and, if not into the GAC or hive, SharePoint-related .dlls developed by us.

Note: there are some specific project details at the end of the post.

Final Summary of Accepted Answer:

• No answer was forthcoming with an alternative method of deploying custom SharePoint assemblies (e.g. not GAC and not hive).
• It is possible, however, to use C# embedded in a page, and you may reference the SharePoint assembly and use it in the code. (see accepted answer for details)
• Many of the things that I had expected would need custom code do开发者_如何学C not seem to, nor does it seem that in many cases it would even be possible/beneficial to do so.

I have a few basic ideas on how it might work ("magic happens"), but, being firmly in the "don't know what I don't know" quadrant right now, I don't know if it can be done, and I don't know whether any possible alternative route would even gain anything beyond just developing directly in SharePoint Designer sans C#/Visual Studio altogether.

ideas:

• Develop with Visual Studio as normal, using WSPBuilder or a stock SharePoint project, but instead of normal deployment, installing the .dll(s) in a non-hive location on the machine, and then somehow including the items as an external resource.

• Create a self-hosting web service that somehow can be called serve up components that can be incorporated into the SharePoint site.

• Develop separate web pages/web controls in a non-SharePoint web project, then including them somehow into the SharePoint site; or, somehow creating a reference to them in the IIS directories

• Develop seperate web pages/web controls in a WebApplication and using the Hostable WebCore to deliver what is needed, and, of course, somehow including the served up pages into SharePoint.

And, my final concern is that even should I figure out the details on the "magic happens" steps, I still would really not have gotten what I want, which is to be able to use the functionality of the SharePoint namespace in a useful way, e.g. connected to the site we are developing, and with sufficient access to do what we need without jumping through too many hoops, either from a developer perspective (e.g. code that's hard to use or maintain), or a bad user experience (e.g. user repeatedly getting login prompts).

(My apologies if the answer is obvious; I'm brand new to SharePoint development, and I'm only experienced with high-level Web development (e.g. fairly simple .ascx/.aspx, and mostly using the designer for pages), so I'm having to get my bearings quickly. When I search for help with the 'obvious' search terms, I get an overwhelming amount of information for normal scenarios, but have not found an answer for this.)

Upon request, here are the details that I can give about the particular project. I currently have information on only a piece of it, and it's a long-term project with a lot of pieces that will build on one another. So, unfortunately, if the solution isn't fairly generic, I will probably have to go the SharePoint Designer route to avoid the risk associated with relying on a method which may not be compatible with pieces that come down the road. Also, I apologize for how generic these are; I am trying to provide a list of capabilities needed as opposed to detailing the actual project.

• ability to have individual user site home-pages that allow them to view various bits of information about projects they own and projects they are involved in
• ability to have site templates that store wizard-type steps to be followed by users
• ability to link the wizard templates to various documents and possibly other things associated with the various steps
• ability to store various associated roles and attributes (such as how much time is allowed for a task to be completed) with the items in the templates
• ability for a user to use the wizard to create instances of the site items and allow or enforce the assignment of other users based on the template attributes
• ability for some roles associated with an item to edit the document and save it back, and to restrict others from editing them
• ability for users other than the creator of the project (probably based on a project role assigned by the user) to view all info (timelines, etc.) and edit all documents in the project
• ability for the associated users that have roles assigned to mark off when they are complete with their portion of the task
• ability to calculate timelines based on info from the attributes for the different items in the project
• ability to notify users (via email and site homepage notifications) in roles that have to take action or are marked as needing to received updates on one or more project items
• ability to lock down project items from modification once a step has been completed; and possibly to unlock and/or retract steps
• ability to automatically create reports and send them to appropriate locations (probably e-mail, but also possibly an administration page on the site, or to another site entirely.)
• ability to mark completed projects and archive them in a separate section only viewable by certain windows groups or groups defined on-site

I also know that there is an intent to greatly increase the scope of this project once we complete the first part to the customer's customer's satisfaction. I am trying to find out more information and will post here if/when that is available.

I realize that some of what's there might really have nothing to do with SharePoint in particular, and some of it may not really give enough information to tell you which feature or other it will need. I am happy to clarify anything that doesn't make sense, but I wanted to try to give a little detail as someone else may have a lot better idea of what SharePoint pieces would be necessary or possible to use than I.

If you can at all wing it, you should see if it would be possible for an upgrade from sharepoint 2007 to 2010 to be made, because many of the problems you are describing are made a whole lot easier to solve in 2010.

Something that would really help me develop a more thorough answer is a very brief description of what functionality you are attempting to achieve.

OK, Thanks for the update. I will try my best to address all the points of the project.

• Your first point is easily available using something called a Mysite.
• For all the points where you are discussing wizard templates that can store documents and associated data, you might want to look into Microsoft Infopath, no guarantee that it'll be a perfect match, but take a look and decide.
• The great part about infopath is that when you combine it with Sharepoint Workflows, you can set rules for doing things, and different views, this will allow you to assign roles associated with editing privileges and such on documents.
• Again, since infopath has the ability to easily submit to a sharepoint list or document library, any data based calculations are as easy as selecting which data you want, and what you want to do with it.
• For the notifications, sharepoint workflows in microsoft sharepoint designer allow easy email creation.
• As far as your last bullet point goes, this is another workflow, and the ability to make sites viewable to only certain groups is a basic functionality of sharepoint.

These are all available in SP 2007, but honestly, it would be financially more responsible as far as the difficulty and length of the project to use SP 2010. Also, the transition process is smooth and you don't really lose anything, just gain. From what you've said though, this might not be possible, which is a shame, but good luck either way!

This part should help you out with the C# pages, here is a basic hello world page.

<%@ Page Language="C#" %>
<script runat="server">
  public void Page_Load(object sender, EventArgs e){
    Response.Write("<h1>Hello World!</h1>");
  }
</script>

I normally code this in sharepoint designer. Also, say if you need to work with Microsoft.SharePoint.dll, provided on the server, you could add this line: <%@ Import Namespace="Microsoft.Sharepoint" %>, since it is a page on the server, you don't need to specifically link it in any way, just that one little line after the page language declaration. Hope this clears everything up!

An option would be to deploy code to the BIN directory instead of the GAC.

The BIN directory runs with minimal trust. However, some things can't be deployed here (like event receivers).

See also, How to deploy a SharePoint web part to bin.

We have a solution which employs IronPython scripts. There's a IronPython web console, generic IronPython event receiver, page, workflow, timerjob, library of scripts which can also be edited through web interface, and a list with necessary configurations. I'm hoping to opensource the core of it at some point, but the full version can do a lot more.

The point is we don't need to do redeploys for every single little thing that needs to be added or changed for each particular customer. Particularly with workflows - we can do small changes without breaking everything that's currently running.