I'm currently reviewing an existing Sitecore installation where the two websites have separate Visual Studio solutions. I've never seen this before, and it doesn't seem like a great way of doing it. Is there any advantages at all to keep them separate or should they be merged into one solution?
In most situations, multiple SLN files will only add confusion, as adam suggested, but depending on the specific setup of how these SLN files are being used, there are benefits in specific situations.
For example, multiple SLN files is very useful if you start getting into a large number of projects, especially if not all projects apply to both websites.
Suppose you have a common business logic layer that handles integrations to back end systems for all websites. This would be a single project referenced in both Site 1 and Site 2 SLN files. However, you might have site-specific logic for Site 2 that is in a separate project and does not need to be visible to the team working on Site 1. That other project would only be referenced in the Site 2 SLN file.
If your project plans involve anything more than editing xslt/css/js, then I think you should merge into one solution. Sitecore has a large codebase for the CMS core, and when you get to the point where you're writing sublayouts, creating xslt extensions, extending the pipeline, creating custom field types etc you'll need to use VS to build the project. Having two solutions will just confuse this.
Best of luck! Adam
Related
I'm a seasoned C++ developer in a new position. My experience is in *nix-based systems, and I'm working with Visual Studio for my first time.
I find that I'm constantly struggling with Visual Studio for things I consider trivial. I feel like I haven't grokked how I'm supposed to be using VS; so I try doing things "the way I'm used to," which takes me down a rabbit-hole of awkward workarounds, wasted time, and constant frustration. I don't need a VS 101 tutorial; what I need is some kind of conversion guide - "Here's the VS way of doing things."
That's my general question - "What's the VS way of doing things?". That might be a bit vague, so I'll describe what's giving me grief. Ideally, I'm not looking for "Here's the specific set of steps to do that specific thing," but rather "You're looking at it wrong; here's the terms and concepts you need to understand to use VS effectively."
In C++, I'm used to having a great measure of control over code organization and the build process. I feel like VS is working strongly against me here:
I strongly tend to write small, isolated building blocks, and then bigger chunks that put those blocks together in different combination.
As a trivial example, for a given unit or project, I make a point of having strong separation between the unit's headers meant for client inclusion; the unit's actual implementation; and any testing code.
I'm likely to have multiple different test projects, some of which will probably rely on common testing code (beyond the code-under-test itself).
VS makes it onerous to actually control code location. If I want a project's code to be divided into an include/ folder and a src/ folder, that's now a serious hassle.
VS's concept of "projects" seems, as far as I can tell, somewhere between what I'd think of as "final build target" and "intermediate build target." As far as I can tell, basically anything I want to share between multiple projects, must also be a project.
But if many intermediate objects now become projects, then I'm suddenly finding myself with a TON of small projects.
And managing a ton of small projects is incredibly frustrating. They each have a million settings and definitions (under multiple configurations and platforms...) that are a real pain to transfer from one project to the other.
This encourages me to lump lots of unrelated code together in a single project, just to reduce the number of projects I need to manage.
I'm struggling with this constantly. I can find solutions to any one given thing, but it's clear to me that I'm missing a wider understanding of how Visual Studio, as a tool, is meant to be used. Call it correct workflow, or correct project organization - any solutions or advice would be a real help to me.
(Note: much as I'd like to, "Stop working with the Visual Studio buildchain" is not an option at the moment.)
The basic rule is: A project results in a single output file [1].
If you want to package building blocks into static libraries, create a project for each one.
Unit test are separate from the code, so it's common to see a "foo" and a "foo test" project side by side.
With respect to your small building blocks, I use this guideline: If it is closely enough related to be put in the same folder, it is closely enough related to be put in the same project.
And managing a ton of small projects is incredibly frustrating. They each have a million settings and definitions (under multiple configurations and platforms...) that are a real pain to transfer from one project to the other.
Property pages are intended to solve this problem. Just define a property page containing related settings and definitions, and it becomes as easy as adding the property page to a new project.
As each project can pull its settings from multiple property pages, you can group them into logical groups. As an example: a "unit test" property page with all settings related to your unit test framework.
To create property page in Visual Studio 2015: in the View menu, there is an option "Property Manager". You get a different tree view of your solution, with the projects, then the configurations, and then all the property pages for that project+configuration combination. The context menu for the configuration has an option to create a new property page or to add an existing one.
[1] Although it is common to have the Release configuration result in foo.dll and Debug configuration in food.dll, so they can exist next to each other without resorting to the Debug/ and Release/ folders. In the General properties, set the TargetName to "$(ProjectName)d" (for Debug configuration) and remove the "$(Configuration)" from the OutputDirectory (for all configurations) to achieve this.
I'm a novice vim user who really likes vim and wants to take it to the next step in my development workflow.
I have 4 different C/C++ code bases which are compiled using 3 different compilers. Each of the code bases has its own project and makefiles for the compilers. I keep the compilers open to compile the different projects. Two code bases are for firmware of a device, one code base is for a library and the last code base is for a cross platform desktop app that uses the library to talk to the device.
I mainly use vim for my code editing, and right now I have several different vim windows that I keep open, i.e. one per code base. I exit the vim editors a lot to open different code files, which is very unproductive. I often have to look up functions in different files within the same code base. I often have to switch between code bases because the software compiled from one code base processes data generated by a program from another code base and I have to double check defines and such.
I'm wondering if there is a better way to organize this using vim? How does an expert vim user set up his development workflow to work with multiple related code bases within the same vim environment and how does he/she navigate the code bases efficiently?
If your projects are related, and files from one project are referred to in another, I would recommend to open them all in one GVIM instance. I personally often use tab pages to segregate different projects within one Vim instance, but Vim (together with your favorite plugins) is so flexible in this regard that virtually any workflow can be reflected.
For a more precise comment and recommendation, your question is missing details like:
How (through which plugin) do you open project files / recently opened files?
Is your current working directory set to the project root, and does this matter to your workflow?
How is your window layout, do you have any sidebars, and how do you organize your files (buffer list, minimized splits, arg list, etc.)?
There are some blog posts about how individuals have set up their Vim environments, but these naturally are bound to personal preferences and the particular programming environment. So, use them for inspiration, but be aware that there's no perfect recipe, and you'll have to find your own, personal way.
I've started my search with WAMP, then tried out a few others until I settled on UniServer which is a portable AMP stack.
The problem is, I might be working on several web projects at a given time period. The two solutions I've come up with are the following.
Have a http.conf file for each project and replace the UniServer http.conf file with the project one whenever I need to work on that project. The only thing that is different with the project http.conf file is the document root folder.
Have several copies of UniServer (it's a portable app, which is awesome), one for each project, each with their own http.conf file.
Solution 1 is the most efficient in term of disk space, but is the least convenient since I'd have to manually replace files.
Solution 2 is the most convenient but it seems inefficient since there are copies of the same files everywhere and their only difference is a small http.conf file.
Question 1. I think solution 1 is the most promising. I was wondering if it was possible to automate the file replacing process with one click or so.
Question 2. Perhaps the best solution is completely different from what I described. If so, please let me know. Thanks.
In this case, I will advise you to use Varal WAMP. It allows you to create several sites easily from its GUI. You don't need to touch configuration files in Varal WAMP. It does it automatically. Alternatively, you can create virtual hosts for each project.
Disclosure: I am the developer of Varal WAMP.
I would like to reuse one installation of Sitecore every time I need to make code changes. I currently have a branch to fix a problem, but now I need to create another branch to fix another problem. The problems are in different websites so I need to keep the seperate branches. I really do not want to create another Sitecore installation for this second branch. Is there a way to "swap" out these solutions and "reuse" the same Sitecore installation?
Mark Ursino's comment about removing the code got me to thinking. Since the solution binded to the Sitecore installation resides in the Website folder, I'll map both solutions to somewhere arbitrary, like "Sitecore Dev Folder", and then map the branch I'm working in to the Website folder of the Sitecore installation. When I change the mapping, the solution will download from TFS into the Website folder (blowing away the existing solutuion.) And that's how I can achieve the "swapping" of solutions.
Yep, we need more info here to really answer the question.
But... in general, I would advise you not to do this. Creating a new Sitecore installation is a piece of cake with the installer, and not exactly resource intensive. You could have it use the same DB if necessary to make things easier.
Mixing two different branches with the same Sitecore instance... it seems inevitable that something would get "F'd up", to use the technical term.
I have to develop two Django projects which share 90% of the same code, but have some variations in several applications, templates and within the model itself.
I'm using Git for distributed source-control.
My requirements are that :
common code for both projects is developed in one place (Project1's development environment)
periodically this is merged into the development environment of the second project (Project2)
the variations are not easily encapsulated within apps. (eg. there are apps. such as "profiles" which vary between Project1 and Project2 but for which there's also an ongoing common evolution)
both Project1 and Project2 have public repositories, so that I can collaborate with others
similarly Project1 and Project2 ought to have development, demo, staging and production servers.
however, the public repository is not on the same server in both cases. So, for example, when I'm developing in Project1, I want to be able to "push" to my github server, but not have Project2 stuff going there.
there are files such as local_settings.py which are completely different between Project1 and Project2, but should be shared between multiple developers of each Project
So what's the best way of managing this situation?
What would seem to be ideal would be something like a "filtered pull" where instead of .gitignore saying "ignore this file entirely", I can say "ignore this file when pulling from that repo" I couldn't see anything quite like that in the documentation, but might there be something like that?
Move the common code to its own library and make it a dependency of those two projects. This is not a question of version control, but a question of code reuse, design and eliminating duplication.
Considering it is a Django / Pinax site, with variants scattered around inside several different applications, I would not recommend using submodules.
The variants should be managed independently in project1 branch and project2 branch, removing the need to "filter" a gitignore result.
If you identify some really common codes, they may end up in a third repo you could then "subtree merged" to project1 and project2 repositories (the meaning of subtree merge strategy being illustrated in this SO answer)
You can use two different git branches for development. When you make changes in one that are common to the other, just git-cherrypick them over. You can push and pull specific branches, too, so that no one ever need know you're working on both of them at the same time.
I would try submodules: http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#submodules
I would make a third repo where I would place the code that Projects share. Then Project1 and Project2 would have their own repo and they can pull from that "shared" third repo.
I think that your idea of "filtered pull" will make it difficult to mantein.