Is it possible to centrally store and distribute code templates such that they can be pushed out to other members of a team?
First I'd keep the code in some sort of version control for obvious reasons, but I'm assuming your wanting to know how to share the templates automatically. I've never done what your asking but the templates should be stored in the \My Documents\Visual Studio 2008\Templates\ProjectTemplates directory in visual studio 2008 anyway. You may be able to map this directory or one of the subdirectories to a network share where you can store your team templates.
Please let us know what the solution eventually is, because this sounds like a very useful idea.
Related
Can I have a freehand in using any arbitrary folder hierarchy within a Visual Studio project? Does the runtime/VS actually care about how I create the folders?
Visual Studio doesn't care about the folder structure you use. Everything is typically tied together based on file types and the references in your project (csproj, vbproj, etc) file.
That said: in general it is best to stick to the conventions laid out by Microsoft for common files, since people are used to look for them in the places.
We have a commercial software product and we are about to hire new people to work on it. This product is in our core business and so we are afraid them to copy our entire source code, leave the company and sell it.
That said, what we'd like is to restrict access to just some parts of the source code using TFS 2010. The Visual Studio 2010 solution has about 14 projects.
We want to allow access not to every project of the solution and even in any allowed project setup what people would see and change for them.
Any ideas?
Best regards.
You can deny permissions on folders in source control. If you have projects in your solution that needs to be shielded, then you have to create a smaller solution that only has the projects that the new employee has access to.
I've searched MSDN and this site (as well as a pile of web searches) and not found anything obvious ... I do see a similar question here about using an existing source control folder -- and the note that TFS apparently stores some project settings there (and thus needs one whether you use it or not).
We're using a non-TFS source control tool -- and I don't want newcomers "accidentally" storing source versions in TFS. So, I'd like to disable the creation of a TFS 2010 source control "tree" when I create a new Team Project in VS 2010.
There may be other solutions to this problem, though, and I'm open to suggestion. For example, if TFS really does need to store some internal data -- how about a way to simply prevent any source code checkins (that is, let TFS use the source control project as needed, but prevent users from adding files)?
TFS has extensive permissions settings.
You should be able restrict check in / access to source tree by permission.
I am the only developer for an application. All the files for this application are stored on the same computer and I am using Visual Studio 2010 Ultimate.
The application has three solutions and these share common items such as some stylesheets, some javascript and shared views.
It's starting to become difficult when I change one file as I have to copy this to the other projects in the other solutions.
Is there a simple way that I could share files. Something that would help me be more productive. Possibly even some single user source code or a way of linking files between solutions.
Hope I can find someone to help me make my life easier.
Robert W
Even if you work on your own I would suggest some kind of Source Control System. Team Server is now free with Visual Studio or you can use open source tools. Like this you can link to source files in other projects and you can reuse your files.
Use Source Control! SVN is free so is TFS with Ultimate.
If its web based files (javscript, pictures, css, etc) use a virtual directory to point to the common code directories.
if its compiled code (C#,VB, etc) you can link the files. When adding an existing file in the dialog it will have a open button, with an arrow down. click the arrow down and "add as link" will be available. It will then use relative referencing to the other file. I use this technique for a SolutionAssemblyInfo.cs file.
I would recommend placing the common files in the same directory as the solution file or no more than 1 folder deep.
We are looking for a Version Control System to change our current Source Safe one. We are using it along with Visual Studio. We've failed so far - and the main reason for it is that all the alternatives we see doesn't support one or more features of VSS, especially one that we use widely - file share! What's up with that?
Alternatives like Source Gear claim to support them, but I gotta tell you that they do that very poorly. Not to mention that they are way slower than Source Safe, and have even more bugs.
What alternatives we do have to source version systems that do support file share? Or is there a reason to not use features like this? Please share your experience and support your comments.
EDIT:
By Share File I mean that I can checkout a file from any project that is sharing it, do some changes and then all get the latest version. It is very useful when working with C++ projects, or even C# Web Projects. I want to be able to share a file without the need to make another library for that.
From MSDN:
Sharing Files or Projects
Visual SourceSafe has a Share command that allows sharing of files or projects. For use of the command, see How to: Share an Item.
When you request file sharing, Visual SourceSafe creates a shared link between the versions of the file in the projects that share the file. When you check in the file to one of the projects, your changes are automatically checked in to all the sharing projects. All the projects that share a specific file are listed in the Links tab for the file.
When you share a Visual SourceSafe project, you create a completely new duplicate project under the current project. All the files in the new project are shared with the corresponding file copies in the shared project, and changes in one are reflected in the other during check-ins to the Visual SourceSafe database.
Other tools do have similar concepts, though not always with the same name or exactly the same semantics. Off the top of my head:
Subversion externals
MKS SI (shudder) calls them shared sub-projects
I tend to avoid them because it indicates there are some other issues with my project. If the resources are needed across many projects, I package them as a library and set my other projects to depend upon that artifact (using a dependency management tool such as Maven or Ivy to manage the dependencies)
In Subversion, you can share a whole folder (and its subfolders of course) with the svn:external property.
And since version 1.6 you can also share files.
In Git, those are called "submodules" - not sure if they work for single files though.
This post http://blogs.msdn.com/ericlee/archive/2006/07/20/sharing-files-in-team-foundation-server.aspx shows how you can accomplish the same thing with Visual Studio and TFS.
In StarTeam you can share files across projects.
I apologize if this is not really addressing the original question but depending on your will to "change mindset" for which version control system to use I would strongly suggest moving to a distributed one such as Mercurial or Git. There are plug-ins for Windows Explorer and Visual Studio for both.
As to specific features such as VSS-style file sharing I suggest setting up a Continous Integration environment like TeamCity and configure it appropriately.
It's a steep curve at first but awesome and time-efficient once your staff and servers know what to do.