This is a follow up question from Team Foundation Server: Getting the Changeset Id from PolicyBase object
I would like to run some code when I check-in occurs. The answer in the linked question above pointed me at this page on MSDN.
I didn't fully understand the explanation on the page and I'm not sure where the check-in event handler would be run.
Should this be in an application that is run on every client machine or is this something that needs to be run on the actual TFS server?
I need to make sure the check-in event handler code is run for every check-in regardless of which client made the check-in.
I tried downloading the sample code available on that Microsoft page but it does not work.
I can connect to the TFS Server. When I click on the "Get List of Registered Events" button, the left hand list box populates with 13 items all with the name
Microsoft.TeamFoundation.Server.RegistrationEntry
As soon as I click on one of the items, I get a TypeLoadException with the message
Could not load type 'Microsoft.TeamFoundation.Server.Subscription' from assembly 'Microsoft.TeamFoundation, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
(Strangely it seems like this is referencing the VS2010 version of the assembly even though it is the VS2008 version that I have linked to the project).
What am I doing wrong here?
Library References
I always found it a pain to try use the TFS2008 libraries instead of the 2010 ones once they were installed. You may be able to change the reference to use a specific version of the DLL, however there shouldn't be any hard using the TFS2010 ones instead as they are backwards compatible.
Event Subscriptions
For TFS2010 it's easiest to drop a custom DLL in c:\Program Files\Microsoft Team Foundation Server 2010\Application Tier\Web Services\bin\Plugins these are fairly simple to write and just involve implementing ISubscriber for CheckinNotification.
Example Code
http://embeddedworkitems.codeplex.com/SourceControl/changeset/view/2611#97271
For TFS2008, or if you like in TFS2010, you need to use the SOAP webservices (or the bisubscribe.exe tool) to subscribe to events and have a webservice yourself for tfs to push events to. This is a much harder way to subscribe to events so if you can use the Plugin method instead I would recommend it (Although it can be more robust and is better for load distribution).
VSTS Subscription FAQ http://blogs.msdn.com/b/narend/archive/2006/07/27/679571.aspx
Subscribing without a Client SOAP Service http://blogs.msdn.com/b/mrod/archive/2006/09/18/761174.aspx
TFS Deployer is a open source project that runs as a windows service and receives event notifications via the SOAP service. It contains a library (which may be reusable) that appears to have some code in it for receiving checkin events
http://tfsdeployer.codeplex.com/SourceControl/changeset/view/57852#2395
Using subscriptions you only need one copy of the application picking up events and handling them, it can be on the TFS server (has to be if you are using the plugin method) but can be on another machine when using SOAP subscriptions.
Check-in Policies an Alternative Answer?
Depending on exactly what you're coding, you may be able to write a check-in policy instead. This needs to be installed on all client machines and won't be supported by all the different clients (eg eclipse) but it may suit your needs. The example I gave earlier of the tool to support embedded workitem codes in checkin comments also comes with a check-in policy to perform other checks
http://embeddedworkitems.codeplex.com/SourceControl/changeset/view/2611#97267
Related
Good Afternoon,
I apologize for the title if it is weird, as I don't really know how to describe this.
To describe my project:
Project has been fine for months
Blazor Wasm project, using Identity Server
Separate Identity grpc service for authenticating logins (hit by Server project piece of the mentioned wasm project)
Both grpc service and wasm use shared organizational nuget packages for identity objects (netstandard libraries)
Key Piece: There are protobuf.net metatype setups for the MSFT dlls that are serialized within Grpc service. E.g. as we cannot set the protomembers for these classes (ClaimsIdentity is one of them, at is the focus of this issue) The metatype setup is to expose the necessary properties to both client and service...
Recently, wasm was updated to net7
When deployed, the metatype setup for ClaimsIdentity blows up, stating that the field "Label" cannot be found. App doesn't run, fails within Program.cs...makes sense...so far...
Now, first thing I did was switch to the dev branch, pull latest, etc. Run locally, don't get the same issue; no issue at all actually, ran without any problems. Do "Go To Definition" and see the Label field within the ClaimsIdentity class (netstandard).
After updating VS, rebuilding, etc... I push out a pacifier release so people can test (removed the ClaimsIdentity line as the wasm piece doesn't need it, we're just reusing a helper method that had it in there). I then go back and try the Go To Definition stuff again, this time, I'm directed to the 7.0.0.0 dll of System.Security.Claims. The class is definitely different than the netstandard one (why I'm now sent to this definition, I dunno, I suspect caching of code/dll I dunno, whatever). Still, I cannot duplicate the issue when debugging.
At this point, after seeing that I'm getting different files on my own machine. I decided to use ILSpy and see if the deployed System.Security.Claims dll is the same....it is not. It is also System.Security.Claims v7.0.0.0, but only has a _label, private property.
Easy fix is just to remove the line throwing causing the issue, but, that is superficial. I'd like to know what I'm missing in why I'm seeing different contents between net 7 dlls. I'm thinking I'm overlooking something dumb, actually, I hope that I am.
Image: Left is Locally Built, Right is what gets deployed (both being Azure Devops and manual publish)
What is a good learning resource for TFS and how to use TFS with Visual Studio?
Specifically, I want to know two things.
Exactly what are the step-by-steps procedures of checking in code. I know that I am required to do a code review. So, after the code review is done by a peer, I understand that this is not enough and the original developer has to click to do something to submit the code into the TFS system. I mean, I want to know precisely what buttons to click on.
I also want to know how to use Visual Studio to look up the actual version. How do I determine the details of what is already checked in?
There are many blogs videos in google. If you want a full detail resource, suggest you directly take a look at our official doc here -- Azure DevOps Server Documentation
A suggested learn order for your reference:
Installation (you could skip this if your company already done this)--
Code -- Build&Release -- Packages-- Test-- Work-- Analysis-- Admin
Tool
TFS supports two types of version control: Git and Team Foundation Version Control (TFVC). One centralized and one distributed. As for which version control system should you use, you could take a look at this thread: Choosing the right version control for your project
For your case, you could easy check the history in server side. It's called changeset in TFVC and commit in Git.
For example, when you check in your changes, they are stored on the server as a changeset. Changesets contain the history of each item in version control.
You can view a changeset to see what the exact file changes were, discover the owner's comments, find linked work items, and see if any policy warnings were triggered.
The same as Git, actually you could find the answer for both question 1&2 in Code part. Hope it helps.
I would like to use VSO as App life cycle management (ALM) tool for other platforms, native android development to be specific. I understand that I can use it for sprint planning and related things.
However, I would like to associate my checkins with BLIs/Tasks/Features.
I think if its achievable then raising pull requests should be as per flow.
Yes, it is possible for you to associate checkins with Tasks or Features work items.
You can do it via opening the work item in IE, and go to All Links tab, select LinkTo and choose Changeset link type. See:
If you are using Git repositories in Visual Studio Online, work items are linked to commits by using the notation #1234 using the work item number. The server will see it and automatically associate the work item with ID of 1234 to that commit and use it in other locations like builds, pull requests, etc.
We call the feature "#mention" and you can see more information about it here: https://www.visualstudio.com/en-us/news/2015-jun-3-vso.aspx
We are using Microsoft Team foundation server for version control where multiple developers are working on a branch and check in and check out the code.
How can a developer A be notified via email or SMS that his code got overwritten during the checkin by developer B.
Developer A needs to know this ASAP because the code changes of developer A will not work when its deployed into QA.
We are tring to save time in a fast paced development environment and trying to avoid code overwrite issues.
The easiest way to allow continuous parallel development and prevent a checkin from one person breaking the code of others, is to use a CI server. TFS supports this through Team Build.
Though it's preferred to run team build on a dedicated build server, it can be installed side-by-side on your main TFS server and it's possible to install the Controller component centrally and use your developer's workstations as agents.
There are two types of build triggers that can help you out here:
Continuous Integration - this triggers a build of all code directly after every checkin. It will tell you quickly that something did not compile. If you are doing unit tests it can even run these and tell you that a test is failing.
Gated - this will force a developer to shelve his code and will only check in the code when the build of the latest version plus the changes in the shelveset succeed. This may seem even better, as the code in source control will never be in a broken state, but in reality I prefer the ci trigger. The main reason for that us that Gated builds can't happen in parallel (due to their nature) and can actually delay the notification that the code is broken.
You can easily configure email alerts through webaccess on specific build outcomes. You can also configure alerts on source changes, but there is no option to only warn people who have edited these specific files before.
You can also run the Build Notification tool from the task tray to show a notification in Windows.
Though this will not tell the person whose code has just been overwritten that it's no longer working, it will tell the person I rewriting that code that he should pay more attention when checking in ;).
Of course you can configure a team alert that notifies everyone when the build breaks (as that's generally called), and there are funny ways to show the build status through small apps like "siren of shame", which provides a build monitor service that can be connected to a USB alarm-light that turns on and provides noise whenever someone does something stupid.
If you need to avoid this problem during check-in & merge, then I would recommend disabling multiple check-out. This allows file to only be checked out one-at-a-time and can prevent confusion on team projects.
If you need to do farther down the line, you can create TFS Alerts when any code is checked in and sent out to a distribution list, but it would not notify when specific contributions from a specific developer is altered - only a list of altered files during the check-in.
we've recently stumbled across the excellent Dispatch for ASP FTP deployment plug in. It looks great apart from one thing: It doesn't work with Visual Studio 2010, at least for us, anyway. (It's supposed to work fine.)
(Yes, we've tried everything: We've managed to get Dispatch working for another FTP site, but not the main one we regularly deploy to. We have managed to connect to our main site through FileZilla FTP, so the site itself is configured correctly. All settings have been triple checked, but the software still throws up weird errors (always to do with its internal libraries).)
So does anyone know of any other comparable FTP-based, deployment plug-in for Visual Studio?
Here's what Dispatch does (and so any suggested replacement must do):
Monitor any altered files
in the project. When a file is
changed, it's added to a list of
files to be deployed.
To deploy these
files to the live site, all we need
to do is click "Upload" and the plugin will
connect via FTP to our live site and
upload the selected files.
We can filter out
any filenames we don't want to be
monitored/uploaded (e.g. .cs or
web.config or /Images/, etc.)
I think that's all the features that we need. Thanks for any suggestions!
Note: If you're wondering why we need such a service, it's because we deploy many site changes over the course of a single day. Publishing the entire project to a folder, zipping it up, then FTPing that zip file, only to have to unzip it, and then install the entire project into the live wwwroot takes far too long. With Dispatch you're able to upload individual files in a single click.
After much back and forth between me and the creator of Dispatch, we managed to narrow down the problem to the library he was using (Rebex FTP). I posted a question about the issue on the Rebex forums, and it was revealed that their software might have a bug with IIS7.5. They suggested a quick hack/fix, which I tested and discovered worked.
Mr. Dispatch then quickly implemented this hack/fix into his software, and lo! I had a fully working copy of Dispatch... So no need for a replacement any more!
(And from what I've seen, there isn't even any other plug-ins offering this functionality, so it's just as well.)
Just an update - Dispatch does not work with VS 2013 so if you have VS 2012 with Dispatch installed, Keep it. Also the website is gone so it looks like all development has ceased. I have been using Dispatch since VS2005 and it has been great for just sending single files up when I need to. Too bad it is gone.
I built a very simple one for myself - you right click the file in Solution Explorer and it then uploads that file based on a settings file you create.
It's super crude but it works and the source is there to make it better if you like -
https://github.com/garazy/vs-2017-ftp-upload
Big enhancements have been added to VS2008, VS2010, VS2012. Below is the article. I found that Microsoft did all the above while I was searching. Since this came up high in what I was searching, thought should share this knowledge.
Deploy a Web Application Project Using One-Click Publish Without Web Deploy