Posted on Mon, 01 Sep 2014 13:00:00 GMT
In the United States, today is Labor Day so I thought I'd not only highlight something Visual Studio related but also some kind of labor saving project. I scanned my queue, looked at a few projects and while they were interesting, they just didn't feel right. Then at the bottom of the list, there it was, today's post. I've had it queued for many months, waiting for the right time...
Why this project on Labor Day? It's something that can save you a good bit of labor, help you in your day to day dev world and it's just kind of cool.
Cool? Imagine your own, inside-the-firewall nuget gallery. You can use this to help manage version hell with third party components, or share components on networks that are not connected to the internet, but more importantly you can use this to provide a very cool in-house way to share your components with your peers and teams
There are commercial (with free community editions) products to do this, like ProGet that might be more feature complete, but we get the source with this one! woot!
Sure you can share packages, create Private Galleries, with just via file shares or atom feeds, but having a web site to search, upload, download and edit is nice and professional feeling. Sure it's not a complete Visual Studio Gallery site, but it's much better than a file share and since you've got the source, you can make it one!
This year at the second MVP summit I presented a new solution for hosting a private extension gallery. Since then I have finished up the code and put it up on the CodePlex site so you can use it as you want to.
In this blog post I will walk through the background and how you deploy and use the solution.
Note: The sourcecode is available at http://inmetavsgallery.codeplex.com/ as a new 2.0 release. I have branched the original source code so that it is still available.
Little more than a year ago, I blogged about how to host your own private gallery for hosting Visual Studio extensions. The solution that I put up on CodePlex (http://inmetavsgallery.codeplex.com/) was a ASP.NET web service that scans a folder or share and generates the corresponding Atom Feed XML that Visual Studio expects when browsing extensions, using the Extension Manager. See the blog post for details on how this works.
Although this solution works fine (we are using it internally at Inmeta) there are some things that have been nagging me:
- There is no easy way to upload or update extensions.
- Since the file system is the data storage, the service rescanned the whole structure on every request, which could become a bottleneck when the number of clients and/or extensions increase
- I miss some of the features that are available in the “real” Visual Studio Gallery, such as showing the number of downloads and the average rating of each extension
The last bullet is what made start looking at how this works in Visual Studio. As you know Visual Studio comes with two extension galleries by default, the Visual Studio Gallery and the Samples Gallery:
The standard Visual Studio Gallery
When selecting an extension here, Visual Studio shows among other things how many downloads this extension has, and the average rating together with the number of votes. Also it shows icons for the extension and a small preview image when selected.
It is also possible to search on different metadata, such as popularity, number of downloads or most recent for example. All in all, this is a much nicer experience than what the was possible using the official private extension gallery mechanism.
When I dug into the details of how this works, it turns out that Visual Studio internally uses a completely different protocol for communicating with these two galleries. It uses a standard (but completely undocumented) WCF SOAP service with the following interface:
So, with a (lot of) help from Fiddler I decrypted the protocol that was used and managed to implement a service that works in the same way that the Visual Studio Gallery does.
The new version of the Inmeta Gallery is a ASP.NET web application that consists of three parts:
- A WCF service implementing the IVsIdeService interface
- An ASP.NET web application where you can upload and rate visual studio extensions
- A SQL database for storing the extensions.
Inmeta Visual Studio Gallery overview
This makes it easy to deploy, it is just one web application that contains both the service that VS communicates with and the web application where you can browse and upload the extensions.
The web application is simple, it shows the 10 most downloaded extensions together with the same information that you see in Visual Studio, and you can search extension by name or description.
The CodePlex release for this solution is a simple web deploy package, that you can deploy to a local or remote IIS web server. I’ve attached the standard files from the Visual Studio publising wizard, so you’ll get the command files that simplifies the deployment, See http://msdn.microsoft.com/en-us/library/dd465323(v=vs.110).aspx for information on creating and deploying a Web Deploy Package using Visual Studio.
Note that the web application is using Entitiy Framework Code First which means that it will try to create the database the first time the code is executed. In order to do so, it must have proper permission on the target SQL server of course. If you need to deploy the database in any other manner, just download the source code take it from there.
It is not possible to add a private extension gallery of this type using Visual Studio, it will always create a Atom Feed gallery extension point. Since these settings are stored in the registry, it is easy to do this using a .reg file.
The registry settings for a Visual Studio Gallery looks like this:
[Click through for the entire post, reg tips and more]
[Also here's the project's codeplex site again too]
Well I couldn't share this without trying it first!
Grabbing the latest source, the project compiled and ran for me the first time with no problems at all (well, once I installed SQL Server... fun how app's complain about not being able to connect to a data source, when clearly the dev wrote that a SQL Server was required... funny that! Anyway.. a somewhat quick download of SQL Server 2014 [might as well use the latest version, right?], install and the app ran the first time with no problems at all)
Here's a couple snaps of the Solution;
And of the site running on my system...
... with a visx I grabbed off the net to share... :)
Finally proof that I can use this just like the Visual Studio Gallery, right from within Visual Studio;
If you've been dreaming of having your own internal Visual Studio Gallery, one where you can play with the code, the Inmeta Visual Studio Gallery is waiting for you...