I'm trying to implement my own feature request to the Visual Studio extension CommitFormatter, and I need the git diff patch for that. I could use libgit2sharp (which I expect to be easy), however, that will pull in an additional dependency. A burden I don't want to add on the extension, if it's not needed.
I expect that it's possible to get the same using one of the APIs of Team Explorer, but I'm a bit overwhelmed with the amount of libraries Microsoft.TeamExplorer.*.dll libraries that Visual Studio contains, and cannot find any good MSDN pages for this.
What I want to achieve is to get the "diff patch" of the staging area, the output that git diff --cached" from the command line gives you, but then using the Team Explorer API. Similar to what libgit2sharp's repo.Diff.Compare<Patch>(repo.Head.Tip.Tree, DiffTargets.Index) would give you.
There is no Microsoft.TeamExplorer assembly that provides a git diff, public or private.
Depending on the version, Team Explorer either uses LibGit2Sharp to interact with the git repository (prior to VS 2017) or uses git (VS 2017).
However, no version actually creates git diff files. The difference view takes the raw files out of the repository and calculates the differences and displays them itself, it does not use patch files as an input or as an intermediate step.
You should either use LibGit2Sharp or call git to produce a diff.
Related
I have a test framework written in C#, I am using Selenium, nUnit and Specflow.
Visual Studio is the tool and I have the normal project folder structure (pages, hooks, steps, features).
Testcases are associated with AzureDevOps and the code is pushed to the repo and pipilines are working great.
My issue is that I want to hide the code under the level of the features.
The idea is that other people could create new feature files and create tests within them, but I do not want them to be able to see the code that is under those Gherkin sentences.
So they should be only able to create and write new features, but not seeing the code below.
Could you please give me some ideas how this can be achieved?
You can import bindings from external assemblies. In SpecFlow.json, add:
{
"stepAssemblies": [
{
"assembly": "Name.Of.Your.StepDefinitions.dll"
}
]
}
While this is typically used as a means to reuse step definitions in multiple projects, you could use this to "hide" the step definitions from test writers. The step definitions would be a pre-compiled DLL file that they can import into a different Visual Studio solution.
This requires two different solutions in Visual Studio:
A regular class library that holds step definition classes. You will probably need to choose .NET Core or .NET Framework 5+, since it must integrate with a unit testing framework. I don't believe .NET Standard would work (but you can certainly try).
Another Visual Studio solution that testers can use, which contains the feature files. This project would reference a DLL file you would create from project #1.
The challenge is disseminating this DLL file. Any update you make would need to be given to the testers' Visual Studio solution. A couple of options come to mind:
Manually update solution #2.
Create a NuGet package for solution #1. Set up a build pipeline in Azure DevOps to build, package, and push this NuGet package to your project's "Artifacts" feed whenever you make code changes. Someone (you or a tester) would need to update that NuGet package in solution #2.
As an alternative, give everyone access to the features and step definitions, but enforce a pull request policy on the repository requiring you as a reviewer. That way you can protect the main branch as the gatekeeper. Testers can submit changes to step definitions, and you are free to reject their pull requests if the changes are not satisfactory.
This, of course, depends on the team structure. If you have outside contractors, sharing the step definition code might not be desirable. Just don't limit people's abilities simply because you don't trust their skill level. Use pull request policies requiring you as a reviewer if they change step definition files. This allows you to benefit from someone else's labor while still giving you control.
After reading about using GIT with Visual Studio solution, I understand that it is preferable to use GIT per project, at least for project which represent a (re-usable) common library. If you have a solution with many projects specific to that solution, using only one repository could be acceptable. For common library, it appears logical to me to have one repository for it in order to be able to fix bugs in the common library from where you detect it and have only one history for all changes.
Using one GIT per common project means that you have more than one GIT repository for any solution that produce an executable that use one or more common library.
According to this: Visual Studio suggestion - Allow multiple Git repositories to be active at once, Visual Studio seems to not support many GIT repository seamlessly. (1995 request)
Does Visual Studio 2017 implement the previous suggestion and manage many GIT repository per solution? (ex: one per project for some projects and one per solution for the solution itself and all other specific projects to this solution)? In other words, does Microsoft will see and manage changes per project/GIT or do I have to works with only one GIT at the solution Level?
Just as a side one (this is not the primary question - the real question is in the previous paragraph): If Visual Studio does not allow multiple GIT repo to be active at once, wouldn't be better to stick with TFS for the moment for any development with common library?
This is a controversial topic. You have a few options:
Mono-repo. All your code lives in a single repository, whether they're split up into separate solutions or not is up to you. If your dependencies are "possibly reusable" then this is the simplest starting point. If you ever really start to reuse your components, you can always break them out.
Separate repositories + Package Manager (npm, Nuget). Put each reusable project in a separate solution, optionally in a separate repository. Have a CI build automatically create a package and publish it to the VSTS package management feed.
SubModules: Create a master repository with your solution, create a separate repository for each reusable component with just the csproj and the sources for that component. Visual Studio 2017 has rudimentary support for submodules. But with a separate git client on the side (Tower, SourceTree) or simply with some commandline mastery, you can make this work just fine.
Subtree: Create a master repository with your solution, create a separate repository for each reusable component with just the csproj and the sources for that component. Visual Studio 2017 has no support for subtrees at the moment. But with a separate git client on the side (Tower, SourceTree) or simply with some commandline mastery, you can make this work just fine.
Multi-repo: Create separate repositories for each project, put a solution alongside it. Manage each sub-component separately and there is no concept of a submodule tracking. Visual Studio will actively fight you in this setup, as it will only support a single master repository at a time
In the end it is your choice. Each solution has its own benefits and there are examples of each out there. The Windows sources are all stored in a single monstrous mono-repo with all its reusable components in the same repository. It has great advantages with regards to knowing which files and which versions work together and which won't. But the repository is so big that Microsoft built GVFS in order to allow their developers to work on a 300GB working directory.
If your components are currently not being re-used and if your tests are more integration tests than real unit tests, then it makes sense to join them up into the same repository.
You can always decide to fix this when the need arises. You can always try to keep these projects as separate as possible. The .NET route will most logically lead you to Nuget though... Also because it handles the versioning aspects and the ease of sharing between projects without having to build the sources everywhere.
While there has not been great support for multi repo solutions in the past, this is about to change. In Visual Studio 16.11 Preview 1, there is now a much more fully featured Git client, multiple repositories are detected and users can easily switch between them using a repository selector in the status bar.
See this blog for further information: Enhanced Productivity with Git in Visual Studio
I would like to make a backup copy of my Visual Studio 2013 MVC application which is only the source code. Such that I could open the solution on a new machine and have it compile after NuGet has downloaded the necessary packages and so on.
I realise that if the project was in TFS or similair I could go to the new machine and download it like that, however I am looking for a file copy solution.
Now while I could ZIP up the entire folder including binaries that seems like a sledge hammer approach. Having looked around there does not appear to be an easy way to do this. Has anyone got a solution or a utility I may have missed?
Use a version control system such as TFS, Subversion, PlasticSCM, git whatever. Seriously. Distributed VCSs like git or Mercurial will let you transport the whole repository easily.
If you insist on a pack&go approach, the ZIP tool of your choice will, most likely, support include / exclude rules based on file name patterns. For example, in Total Commander it's easy to exclude bin and obj folders.
I am not sure how this feature is called in English but there is something like Clean solution in Visual Studio. This will delete all the binaries and stuff that can be generated. I am not sure it will also delete NuGet downloads but you may give it a try. Afterwards, you can simply copy the project or solution folder.
I'm trying to get our SVN and TFS repo structures finalized for a new mobile project we are starting. The code is in 2 (or 3) sections:
REST/Web API/service for all database interaction
The "web" code, which consists of css, html, js (and Angular) etc
iOS project...Phonegap/Cordova code
I've already created a project on our Jenkins (iOS) build server and have that configured to build the iOS source code, create an IPA file, and upload to TestFlight for the testers. I also have created a TFS repository for the REST/Web api code that is building successfully, I'm just waiting for my permissions to deploy this code.
So, as you can see, lots (not really) of moving parts to this application. The problem that I have now, is that there is code that is technically "shared" between the iOS code and the Web (service) code, which is all of #2.
I've read about svn:externals, but obviously that is for code that is encompassed COMPETELY in SVN (I think). How can I accomplish #2 to work with both source control systems?
Edit: I am restricted to using SVN and/or TFS for source code repository.
Use Visual Studio Tools for Git (2012 or 2013) and switch all development to git? This also allows you to setup TFS 2013 (or Visual Studio Online) as your git server should you want to. Or use svnBridge for TFS and see if you can get that to work with the svn:externals (never tried that angle before).
You could also use git svnand git tf in combination with local git submodules in a local git repository (but store the remote masters in tfs and svn respectively), but that's making things more complex than need be.
And you can also use a build system to generate a NuGet package and reference that from Visual Studio/TFS, that way you'd have a single source for the package (hence easy reuse) and each application can be built in its own ecosystem.
And you can always install AhnkSvn or VisualSVN and store all the Visual Studio stuff in Subversion too.
I am writing a utility that automates some SVN processes. All of the machines that this utility will be deployed to have TortoiseSVN installed - however, they might not be the same versions. I understand that TortoiseSVN is statically linked to a specific version of a SVN library, and that this is upgraded often.
What I want to avoid is having the checkouts that my utility creates and updates be incompatible with TortoiseSVN. My initial idea was to use the TortoiseSVN command line arguments to invoke the dialogs, but they all require user input. I would rather this all be automatic, and the output of the SVN commands be sent to stdout.
Is there any way that I can gain direct access to the SVN library that TortoiseSVN uses internally? Or are SVN checkouts guaranteed to be (forwards and backwards) compatible between minor version differences? Upgrading the SVN binaries my utility uses per major version of SVN wouldn't be too much of a problem. I just don't want to mandate that every user use a specific version of TortoiseSVN.
To those who suggest that I use the command lines tools for SVN:
The clients may not have the SVN command line binaries installed - and even if they do, there would be differences between the version that TortoiseSVN is linked to and the version the command line binaries are linked to - which could lead to incomparability.
You may use the sharpsvn api for direct access the svn server.
It's xcopy deployable and isolated from other svn or tortoisesvn binaries.
I've tried this a few times and the differences between certain versions of SVN code have sometimes been substantial. My guess is that you will have to specify that your code is only compatible with certain version(s) of SVN.
If your application needs are simple, you might be able to execute command line instructions?
Another option would be to try and write your code to read the SVN version, and then handle the differences in your code. That would be a nightmare IMHO.
TortoiseSVN installation has command line tool named TortoiseProc.exe. See "Appendix D. Automating TortoiseSVN" topic in TortoiseSVN's help book (which is included to TortoiseSVN installation as well).
I'm used to a setup that uses TortoiseSVN and also some scripts that rely on a seperate svn commandline client.
In general we don't have issues.
The main compatibility concern is if the working copy format changes.
This happened between svn 1.5 and 1.6.
An svn 1.5 client could not work with a 1.6 checkout.
See:
http://subversion.apache.org/docs/release-notes/1.6.html
On past projects I have also used the TortoiseProc commandline tool - note that it can be called in a manner that removes user interaction if no errors occur see /closeonend in http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-automation.html
I don't believe there is any way to access the base svn client code inside the Tortoise binaries.