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:
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.
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.
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!