2

I'm wondering if anyone can point me at the best practices for installing a complex service (basically, an entire web application) into SP when doing a feature install.

We have an existing web application that we'd like to package into a WSP. The application is a set of ASMX web services that are used by the web parts that make up the "meat" of the feature. It also has some ASPX pages for administration purposes.

The problem is that this web app depends on a lot of low-level infrastructure such as http modules & handlers, new DLLs, etc. It has its own web.config with app settings, etc. and as such doesn't fit in well as a drop-in to the _layouts directory, which is where I'd normally put our custom pages.

I see that in 2010 there seems to be some sort of "SP Service Provisioning" classes, which might let me install something into IIS, etc. But I'm not sure that's the right direction, and in any case I need to do this for SP2007.

So... anyone have any opinion about the best way to use WSP feature installation to basically install an entire new web app, or vdir within SP?

[Please let me know if I need to clarify anything - I might not have explained it well]

Thanks!

Improve this question
2
  • 1
    I cannot answer this but in terms of clarity have you considered having a seperate msi which deploys the SP artifacts via WSP but seperately installs your webapp and associated services into IIS? If so why was this approach not viable? Ongoing maintenance? I am not a deployment expert, hence not venturing an answer to your question.
    – Charles Lee
    Commented Mar 5, 2010 at 9:32
  • Thanks Charles - yes, this is the way we do things now. We're just looking to make the installation a more palatable experience for those who don't want to do a separate installation process when they're "just adding sharepoint web parts"
    – SteveEisner
    Commented Mar 8, 2010 at 19:46

2 Answers 2

Reset to default
2

I think you might need something like:

  • a WSP to lay down all the files which can go into locations targeted by the WSP framework e.g. assemblies
  • a farm-scoped feature with a timer job to copy other files to the physical directory you want to use, create the IIS virtual directory etc.
  • code in a web app-scoped feaure receiver if you need to make any amendments to existing web.configs

I think the biggest problem could be permissions. I'm not sure the timer or administration services would (should) have the permissions you'd need, specifically:

  • Adding files to a location which isn't related to a SharePoint web app
  • Executing the code to add the IIS virtual directory

I think such challenges are the reason most vendors typically use msi packages which would run in the context of a local administrator account.

Improve this answer
1
  • Thanks, Chris. As noted in a comment on the question, doing it the MSI way is our current deployment method. I should have been clearer about this in my question - we're trying to find a way to do a single, integrated installation process with SharePoint in control. Since what we're ultimately doing is installing a bunch of support files & services for a set of SP web parts, it seemed that the deployment should be set up that way too. I'll look into the method you suggested! And if that doesn't work, we can fall back on the current method :)
    – SteveEisner
    Commented Mar 8, 2010 at 19:52
1

I would investigate the _layouts option a bit more.

Perhaps you can introduce a folder level web.config in /_layouts/yourproject that overrides/clears most of the SharePoint stuff (clear httpmodules etc).

If you could get this to work, simply by introducing the right web.config, it would save you so much time/effort in terms of maintenance and writing custom deployment mechanisms.

Improve this answer
2
  • 1
    Yep agree - but this will only work depending on what needs to go in the web.config. A web.config which is just in a folder rather than at the application root cannot define all the things that the latter can (i.e. items defined as 'MachineToApplication' in machine.config). Even if it turns out the desired configuration can be done with a folder-level config file, it would be very painful if a new configuration element was required one day (i.e. post go-live) which either could not be implemented or required a switch to the other approach at that point. Otherwise I definitely agree!
    – Chris O'Brien - MVP
    Commented Mar 5, 2010 at 12:31
  • Thanks to both of you! I agree that it would be best if we could just drop this into layouts, a directory that's pretty easy to provision with standard WSP installers. But yes, I tripped over the MachineToApplication issue a few times while narrowing down our web.config so it could fit into _layouts, and that makes me uneasy, because as Chris commented, it seems like a very tentative solution.... But I'm still rooting for this solution since the actual deployment would be easier!
    – SteveEisner
    Commented Mar 8, 2010 at 19:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.