2

By Sitecore website root I mean the SIM-installed site at C:/inetpub/MySCSite1/Website

Or should the Visual Studio solution, and thus source control base, be OUTSIDE/separate from the Sitecore website root? like C:/MyProjects/Sitecore/MySCSite1

1
  • 2
    What are some possible consequences if you do one or the other? How does it change if you want to set up build and deployment automation? Commented Oct 6, 2019 at 3:44

2 Answers 2

5

You always want to put your visual studio solution outside of the website and deploy into it.

Upgradability

Unless you are going to add 10,000 files to your gitignore file, you are going to have the base Sitecore files in your solution. When you upgrade your website, you are certainly going to miss some files. Then you will overwrite your upgraded Sitecore files with the old files in your solution. This will cause many strange behaviors and lots of errors about not being able to find classes.

Can't do helix

The first major reason is that you cannot use Helix principles if you are in the website folder. Having a solution in the website folder restricts you to only one web project and many libraries. Using the Helix guidelines, you are going to need many web application projects.

Prepared for CI/Deployment

Your visual studio project should be designed for each environment that you are going to need to deploy into. This means that if you are going to use gulp or msdeploy to deploy into prod/stage, you need to be able to test it in dev. Having a solution in the website, would not alert you to what files, dlls, etc.. that you are missing or not deploying properly.

Nuget

By having your solution in the website folder, then you are most likely going to use the dlls in the bin as your reference dlls. But you should 100% use the dlls from NuGet. This allows you to build and deploy to environments without having 200 MB of dlls in your source control.

1
  • Hi Chris! I've heard you mention some best practices before, such as Nuget for Sitecore framework dll's (I assume that's what you mean). Is there documentation/blog which describes these best practices for Sitecore that you'd suggest?.. Quick examples of ambiguity: should .config files be in source (there are many many .config files), should all the .config.disabled choices be in source, should sitecore .dll's be in source (otherwise how do you build your project to publish in the first place without references to Sitecore libs) Commented Oct 8, 2019 at 15:02
3

Yes, you can create the Visual Studio project inside the webroot of a Sitecore install. But It is not a recommended practice.

Things to consider for Visual Studio project inside the webroot-

  • Changes to the Visual Studio project are immediately available on the website. But every config update and build will recycle the app pool even we required that changes or not.
  • Can use bin folder of Website root for the assembly references, but it is not recommended to use assembly references in this way
  • Auto build and deployment will be a challenge
  • The Sitecore upgrade will also a challenge

Creating the project outside the webroot has a number of advantages and is a recommended practice:

  • It creates a clear separation between the files of your solution and the Sitecore files.
  • You can upgrade Sitecore or create a new Sitecore instance and use the same Visual Studio project easily.
  • It is easy to backup, restore, and move projects.
  • You will not get the changes immediately and need to VS publish your changes, which is good most of the time.
  • Auto build and deployment is easy.

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.