Is there a generic programmatic way to use the Visual Studio Source Control Plugin API to check out files, browse repositories and check in files?
I am aware that I can use the TFS API to acheive the same results. However I would like to be able to execute source control commands generically enough without having to worry about which source control is currently used (TFS, SVN, git .. etc)
Note: I am using a Visual Studio package to develop that. So I am in a VS Shell environment
As all SCM systems are built by different vendors there is no such abstraction later. You will need to create custom code for each system and make sure that each systems API is available to do so.
Related
I am new to TFS and I'm trying to add some custom library files that the whole team uses into Team explorer in Visual Studio. It's library files of Sahi Testing tool so that any changes made to the files can be seen on all machines. I have tried searching online but could not find exactly what I want. Help
Basically, you have the following options:
If you have Nuget Packages for the libraries, you do not necessarily have to add the packages to source control and restore them when you need them. See this link for details.
As an alternative, you can add libraries as binary files to source control so that each developer or build server can retrieve them together with the source code. It's a good practice, to add them to a special location so that they are located in one place and not spread over the solution. However, only use this approach for binaries that do not change too often. Otherwise, you might bloat your TFS database if the files are large and change very often.
I just installed AnkhSVN to have subversion support from within Visual Studio 2010.
I noticed I had to go to Tools > Options > Source Control to select the current source control plugin.
At the moment, I'm working on multiple projects using different version control systems. For instance, I also have some projects in Mercurial, for which a VS source control plugin is available.
Is there any way to specify the source control plugin on a per-solution basis? Or can VS detect the used vcs automatically? What are the best practices in this respect?
Edit: a google search led me to How to configure Visual Studio to use different source control providers and Can Perforce and SourceSafe co-exist in Visual Studio?. Both cover the same ground, but appear to be specific to specific vcs and lack a satisfying general answer. I'm looking for a general answer here.
There is unfortunately no good answer here. You will simply have to go in and manually change you visual studio source control provider settings before you open the project. This is a limitation of how this particular plugin system works, and will probably take a new version of visual studio to specifically address it.
This is an instance where visual studio works better for the enterprise shop with standardized source control tools, and not as good for a contractor working with multiple clients across an array of technologies.
Source control provider auto switching based on reserved directory presence can be done with a VS extension as described here.
i was in the process of evaluating different tools available for creating the setup package for a newly developed software. i came to know about the visual studio's setup project facility, but couldnt get much help on its capabilities.
Can someone tell me if this tool helps me achieve the below given features
copy/paste files and folders.
create a text file, and input certain values to it.
make/update entries to the registery
check for certain services running on the local/remote system
reading certain environment variables from the system.
running a third party application.
what script language does it support
Other than Visual Studio, I had evaluated InstallShield which does provide support for all the above mentioned actions. But Visual Studio is already available, I was curious to find if it matches InstallShield in capability?
Here is the Visual Studio support:
Supported
Not supported
Supported
Not supported
Not supported
Somewhat supported ( supports prerequisites )
No scripting support
What is not supported can be implemented through custom actions (custom code).
The custom code is in form of custom actions, which can be DLLs, batch files, executables or VBScripts, with DLLs being the method recommended by microsoft, written in C/C++.
Here is some more information on what custom actions are and how such custom actions are integrated with the installer:
Custom Actions
If you want an alternative, you can try Advanced Installer. It supports everything you need and it's cheaper than InstallShield.
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.
I am new to config / build and release management.
We are using VSS for our config management tool and also we are using SharePoint in our project. In VSS we have lot of files like .cs, .snk, .dll, .pdb, .css, .js, .xml etc.
We want to make a build/release as a package for testing that should be an internal delivery. I don't have any idea how to create a build/release package. Can any body give me any suggestion/information how to do this?
One more thing: due to some internal reasons we can not use any free ware or any other software. Is it possible to do this with visual studio?
I agree with Mitch, not possible with VSS only. But...if you don´t wan´t to use TFS (Team Foundation Server) which is the preferred option I would recommend looking at Cruise Control for doing your builds.
The other option is to use some sort of custom MSBuild project to package your stuff together, use WSP Builder to make that process a bit better. The best way to automate this is still to use TFS or Cruise Control to build your custom MS build project.