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?



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.

| 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

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.

| improve this answer | |

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.

| improve this answer | |

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)
| 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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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