Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I'm starting to develop Silverlight applications for SharePoint and have been advised to create a Document Library to store the executables.

I'm just wondering...

Are there any advantages in doing this rather than creating a folder in the file system and hosting the file there...?

Which method is being used in the real world?

Does it even make a difference?

Cheers!

share|improve this question
add comment

4 Answers 4

up vote 2 down vote accepted

You have versioning & permissions in a document library.

Plus, it's easier to load from within a SharePoint Silverlight web part when it's in a document library (you can't load it from the file system if you want to host the Silverlight app in SharePoint, unless you put it in LAYOUTS and load it in manually (probably a bad idea)).

ADDITIONAL: If you want your solution to work in Office365/hosted SharePoint environments - a document library is your ONLY option.

share|improve this answer
    
Versioning and permissions could be convenient but I'm wondering if there's any additional advantages to hosting in a document library as opposed to creating a virtual directory under the Sharepoint site and hosting there instead. –  Sambo Mar 25 '11 at 1:52
add comment

Does it make a difference? The number hours SharePoint has saved me I've lost documents only for a copy to be easily recovered from SharePoint is too many to count.

  • Versions & permissions are a great & obvious place to start.
  • Search (including metadata) is another
  • Content organisation using content types & metadata is really useful.
  • Plus a ton of other features that could benefit your company.

Ultimately it depends on your needs & budget. Start using SharePoint Foundation with a small group of people who commit to using it. If it helps, great, if you keep using a file share, nobody outside your company is going to lose sleep over it.

share|improve this answer
add comment

You can do both at the same time. Deploy your file using a .wsp to somewhere on the file system (probably inside FEATURES\MyFeatureName\ ), and then make it GhostableInLibrary.

This means that initially, though your file appears to be in a library, it's actually being served from disk - which is faster.

However, the file is in a document libary, so you can check it out and edit it, etc.. However, if you do, it is 'unghosted' - that is, the changed file is save to and served from the database. The local version on the file system will no longer be used.

This isn't a bad description: http://gvaro.wordpress.com/2009/12/15/ghostable-vs-ghostableinlibrary-%E2%80%93-a-lesson-on-custom-form-deployment-in-sharepoint/

This unghosting/ghosting of files is what happens with SharePoint designer when you customize(unghost) a page, and then reset it to the site definition (re-ghost) the page.

share|improve this answer
add comment

Playing devil's advocate to the other answers... the only things I can think of:

  1. The file system could be faster than going to the database
  2. You'd want to include your Silverlight applications in a solution file (easier deployment)
share|improve this answer
    
Even if the Silverlight application is in a solution file (good practice) it can still be deployed into a library inside the virtual file system. –  Andy Burns Mar 25 '11 at 15:58
    
Making it ghostable could make sense especially if you want to customize it per site. Otherwise, I don't see a reason to (limit changes to being deployed via WSP). –  Kit Menke Mar 26 '11 at 21:05
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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