installing tfsbuildextensions to GAC

Feb 16, 2012 at 11:59 AM

i've seen others referencing just installing the tfsbuildextensions into the GAC (as opposed to doing the "recommended" approach of a class library, etc), but when i try to install i get "strong name" issues (not signed). how do others accomplish this? are you building and signing from source?

Jun 1, 2012 at 7:34 PM

I do have the same issue. Can't TfsBuildExtensions.Activities.dll.  Is this solved?

Aug 28, 2012 at 4:29 PM

I would like to get these dlls strong named as well. Hopefully this can be done for the next release.

Coordinator
Aug 29, 2012 at 11:02 AM

do you want these in the GAC on your dev machine or the build server?

Mike

Developer
Aug 29, 2012 at 11:23 AM

What is the scenario(s) in which you need the activities in the GAC?

 

Aug 29, 2012 at 12:12 PM

For me, I need them on the build controller/agents. We have many collections and team projects. It is easier for us to add our custom activities to the GAC, then to have them in source control for each collection.

If there is a way to get them to load on the build controller/agent without having to add them to the GAC or source control, I'm for it.

Developer
Aug 29, 2012 at 12:47 PM
huntantr wrote:

For me, I need them on the build controller/agents. We have many collections and team projects. It is easier for us to add our custom activities to the GAC, then to have them in source control for each collection.

If there is a way to get them to load on the build controller/agent without having to add them to the GAC or source control, I'm for it.

I'm assuming you have discarded the option to configure on the build controller the path to custom assemblies.

Is that it?

You consider easier to manually install the assemblies on the GAC when you install a new build agent machine instead of configuring it once for each controller?

Aug 29, 2012 at 1:14 PM

Correct. Because we have many collections we decided it would be easier to maintain locally on the build machine then to have to maintain the files in each collection. It's too bad there isn't a probing path on the controller like there is on the dev machine.

Developer
Aug 29, 2012 at 1:42 PM
huntantr wrote:

Correct. Because we have many collections we decided it would be easier to maintain locally on the build machine then to have to maintain the files in each collection. It's too bad there isn't a probing path on the controller like there is on the dev machine.

But you are going to have at least as many build machines as the number of collections so the effort is more or less the same 

And to script the update on multiple collections (by this i mean updating the activities assemblies) is quite easy (rather than to log on all machines and update the gac (granted that can also be scripted)).

I understand your scenario and unless i'm missing some data in the medium term (even in the small term) you will be better served by using the custom path assemblies. 

You will also have added benefits, like traceability and auditability without any costs or effort.

Just to be clear, not trying to make any judgement on your choices, just trying to understand them.

May 3, 2013 at 3:46 PM
I'd like to have strong names to be able to easily add these activities to the toolbox. It is how I use TFS Versioning (also on CodePlex), and it works great.
May 18, 2013 at 1:07 AM
I guess you never heard of SMS, SCOM or LanDesk.

You don't have to log on to a machine to install on the GAC, you just generate an MSI and deploy it to any machines you want.