- When do I need to share my code base?
- There are other ways I can accomplish that. Why use SourceShare?
- What Visual Studio versions are supported?
- What editions are available for Visual Studio SourceShare?
- Is it possible to link projects/folders outside the current solution?
- Is it possible to link only a folder, not the whole project?
- Is it possible to link a project/folder in a subfolder of the target project?
- Can I use SourceShare in a team environment?
- What happens when a linked file is deleted from the target project?
- Will Visual Studio SourceShare slow down Visual Studio?
- Can I lose (unintentionally delete) a file because of SourceShare?
- Can I link projects created with different Visual Studio versions?
- SourceShare sometimes tells me that it needs to save some projects and asks me what to do. Why is this?
Whenever a class or file needs to be used in more than one project, the same file should be used, not a copy. Without SourceShare, this is not always as easy as it might seem. There are different editions of the .NET Framework - the desktop edition, the compact edition for mobile devices, Silverlight for RIAs, Mono and others. If you create a project targeting one of those framework editions, you cannot add it as reference from a project that targets another. This means you cannot reuse your code, which is a major drawback. This is where SourceShare helps. It allows you to reuse code in a different way - by linking source files, not assemblies.
Yes, there are other ways. In a Visual Studio project you can link files from the file system. This is easily done using the "Add as link" option when adding an existing file. Actually, this is exactly what SourceShare does for you in the background. But with SourceShare it is done automatically. You only define which source project/folder is linked to which target project/folder.
While the manual approach might be sufficient when you want to link several files, for more complex projects it is highly ineffective and error-prone. Our research showed that the manual linking often causes worse project architecture because developers tend to create the class in the target project, sometimes planning to move it to the source and then link it later. This is normal since the job of moving the files and linking is something that is usually not related to the current task and the focus is elsewhere.
The supported versions are: Visual Studio 2005, Visual Studio 2008 and Visual Studio 2010. "Express" editions are not supported, since they do not support extensions.
Visual Studio SourceShare is available in two editions: Basic and Professional. The Basic edition is free, while the Professional is not. As you might guess, the Pro version has more features. However, you should know that the Basic version is fully usable and is probably better than anything you could achieve without Visual Studio SourceShare. You can evaluate the Professional version 30 days for free.
You can compare the editions here.
Yes. This is often very useful since you normally do not work with the linked source project only with the files you have as links in the target project.
Yes, this is possible in the Professional version.
Yes, this is possible in the Professional version.
SourceShare is designed to work for both single developers and in a team environment. All paths are stored as relative paths and all settings are stored in the project files. You should have no problems using a source control system or other team utilities without some special actions due to using SourceShare.
Global settings are stored using the Visual Studio standard mechanism so they could be transfered, if necessary.
When you delete a linked file from a target project, SourceShare first checks if this file has been created as a result of a linked source project. If yes, the user is presented with options to delete the source file, create an exclusion rule or do nothing. This way you can work with the source project directly from the target project. This helps you concentrate on what you are doing, without caring about how the projects are linked.
Visual Studio SourceShare is designed with performance in mind. During Visual Studio start-up, only a few minor things are initialized, which is very fast. The other, slower things, are only initialized when they are first needed. On loading a solution, Visual Studio SourceShare has to synchronize all projects that has links defined. For big projects and slow PC-s this operation might be slow. In order to maintain fast solution loading time, we have created an option for delayed synchronization, which is on by default.
No. In most cases Visual Studio SourceShare only creates and deletes links to files, not actual files. Indeed, there are some cases when SourceShare needs to move real files from one project to another. This is done very carefully to assure no files are lost in the process. First, Visual Studio SourceShare checks whether the destination file exists. If yes, moving is aborted. If not, the source file is copied to the destination path. Then the destination file is checked for existence. Only if it exists, the move operation is considered successful and the source file is deleted (moved to the Recycle Bin).
Note, that in some cases it may appear that you have lost files. When SourceShare moves files from one project to another, it cannot always automatically save the project. This depends on a setting. However, if the project is not saved for some reason (power loss or something like that), the file(s) are moved, but the project does not know about them. You will have to include them manually.
Currently, no. In order to synchronize the target project, Visual Studio SourceShare needs to open the source project. It tries to open it using the instance of Visual Studio in which the target project is opened (an instance of the same version actually). For this to succeed, the target project must be of the same Visual Studio version.
Although the appearance of this dialog might seem random, there is strong logic behind it. When SourceShare make some changes it needs to save those changes. However, it is not possible to save only the changes from SourceShare - the whole project must be saved. By default, if the project is unchanged (not dirty), saving is done automatically. If the project is dirty, the user is given the option to save it or not. The project might contain some changes that the user do not want to save to the file yet.
This is the default behavior, but there is an option to always save projects or always ask.