Introduction
Visual Studio, since version 2010, manages extensions and updates using a central (online) repository. This central place enables to everyone, not only Microsoft, to share tools/controls/templates and more - including updates - with everyone using Visual Studio, by uploading a single file...
But what, if you have some extensions that are so specific, that it's pointless to make it public. Obviously you have two options - manual installation or private repository...
Manual installation is so old-fashioned, so I will show you how to create, and maintain a private repository...
Background
I'm a kind of developer, who do not like to open too much applications/windows while working. For that reason I use a lot of Visual Studio extension, to incorporate functionality into my main environment.
Another reason to use extensions, comes from my job. I'm working on big project (hundreds of web pages), where my job is to create a tailored framework for those developers, whose job is to create the actual pages. As those pages are based on templates (several of them) and use my home-made engine, creating an extension to publish the templates is the shortest way to success.
The private repository became useful when I realised that not only I have to publish the extensions to several (about 12) computers, but I also have to deal with updates...
Important Note
Visual Studio supports different types of installation packages for extensions (VSIX, MSI, VSI), but in this article I'll explain about the one, all your extension projects from the SDK will create for you - VSIX.
Using the code
You will see no attached code to this article. The reason is that the only 'code' you will see is some XML, that used to define the private repository, and that XML will be maintained manually for now...
What Repository Is
So how Visual Studio knows, what extensions are in the repository and what updates are available? The repository presented to Visual Studio as an XML file. This file contains entries in the format of atom feeds and Visual Studio scans those entries to see what in the repository.
Note: The main repository Visual Studio uses actually a service (implemented in WCF) to serve the content from a central database. You can find a lot of solutions online, that use the same approach, if you interested in… I use the single XML file approach as it is much more simple and easy to handle in case of a few (one to hundred?) extensions. To write a full service for that few extensions is somehow a waste…
Visual Studio enables multiply, active repositories, so all we need to do is creating an XML file in the correct format and point Visual Studio to that file…
The XML File
<?xml version="1.0" encoding="utf-8" ?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title type="text">My Gallery</title>
<id>591c105e-bd42-4008-bcef-d822c1bd7607</id>
<updated>2015-02-25T17:00:00Z</updated>
<entry>
<id>8936414f-bf3f-4f33-89aa-6e3e1b0985cd</id>
<title type="text">My Extension</title>
<summary type="text">Summary of My Extension...</summary>
<published>2015-02-17T15:00:00Z</published>
<updated>2015-02-25T15:50:00Z</updated>
<author>
<name>My Company</name>
</author>
<link rel="alternate" type="text/html" href="http://codeproject.com"/>
<link rel="releasenotes" type="text/html" href="http://codeproject.com"/>
<link rel="icon" type="text" href="icon.png"/>
<link rel="previewimage" type="text" href="preview.png"/>
<category term="Tools" />
<content type="application/octet-stream" src="MyExtension.vsix" />
<Vsix xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://schemas.microsoft.com/developer/vsx-syndication-schema/2010">
<Id>8936414f-bf3f-4f33-89aa-6e3e1b0985cd</Id>
<Version>1.1</Version>
</Vsix>
</entry>
</feed>
The XML - as mentioned before - based on the atom feed format, which defined in RFC4287.
RFC4287 - Introduction:
Atom is an XML-based document format that describes lists of related information known as "feeds". Feeds are composed of a number of items, known as "entries", each with an extensible set of attached metadata. For example, each entry has a title.
The primary use case that Atom addresses is the syndication of Web content such as weblogs and news headlines to Web sites as well as directly to user agents.
The atom format defined as an extensible one and, of course, Visual Studio use a version extended in such way can be used to deliver VSIX files for installation...
Now let see what all those XML tags mean... The format have two main parts, the header and the entry, where entry can be repeated infinite times...
The header
This part contains three tags:
| title
| As the name suggest, this is the title - name - of the repository. This property not actually used by Visual Studio and more for the human reader...
|
| id
| A unique id of the feed. It can be any kind of unique id, like 'my-unique-id-1234', but I would say a good UUID (GUID) will do the job.
|
| updated
| The date/time when the feed last updated. The format (here and at all other date/time tags) is YYYY-MM-DDThh:mm:ssZ...
|
The entry
A feed can contain infinite entries, however, if the number of entries you handle grow too large, you should consider to create (set-up) a service based repository.
| title
| This will be presented to the end user as the name of the extension.
|
| summay
| Some explanation about the purpose of the extension. It will be presented to the end user too...
|
| id
| A unique id of the entry. It MUST be exactly the same as to id of the VSIX package!
|
| published
| The date/time when the entry originally published.
|
| updated
| The date/time of the last update of the entry.
|
| author/name
| The person/company created the extension. It will be the value of the 'Created by' block.
|
| link[alternate]
| A link to a page where end user can get more information about the extension. Optional.
|
| link[releasenotes]
| A link to a page where end user can follow the feature-history of the releases over time. Optional.
|
| link[icon]
| An image of 32x32 pixel size (not necessarily icon format) that will be displayed next to the name of the extension. Optional.
|
| icon[previewimage]
| An image of 200x200 pixel size. This image will be displayed in a side-bar and the purpose of it to give a taste of how the extension looks-like when in action (kind of screen-shot). Optional.
|
| category
| This tag enables to divide the repository into groups. The term attribute will hold the name of the category (it's a free text!). All the extensions with the same term will be presented to the end user under that name (in a tree-view). Optional but very useful.
|
| content
| This tag points to the VSIX file will be installed if end user decides to use the extension.
|
| Vsix/Id
| The id of the VSIX package.
|
| Vsix/Version
| The version number of the VSIX package.
|
That's it. It is a very simple XML file, and you will have no problem to maintain it with even notepad...
Now let see how it looks like from inside Visual Studio.
Add Repository to Visual Studio
To manage repositories for extensions open the Tools->Options menu. From the left-side menu choose Environment->Extensions and Updates. Notice that the build-in repository not listed here, as that repository is integral part of Visual Studio...
In the right-side window hit the Add button, fill the fields of Name and URL (at the bottom), hit Apply and OK...
The name is how Visual Studio will present the repository to the end user and URL is a link to the XML file we just described...
You are done.
Use the repository
Now to the simple magic...Open the Tools->Extensions and Updates menu. In the left-side bar you have a tree-view, where the second leaf is Online...Open it! Do you see your repository (if no, you missed the declaration in the previous step). If you open it you will see all the categories you defined and all the extensions by categories (choosing the root of your repository will display all the extensions from all the categories)...
Now you can install your extension the exact same way you did it with 3rd party extensions from the Visual Studio Gallery.
Now imagine that all you co-workers did the repository definition from the previous step...How easy is to deploy a new extension...Like in your dreams...
Update
It is easy to add a new extensions to your repository. Copy the VSIX file to the folder and update the XML file. Everyone opens the repository from Visual Studio will see it immediately. But how to update an existing one?
The first step is exactly the same as for new - copy the updated VSIX file over the existing one. The second step involves - of course - the update of the XML file.
To be honest, the one and only tag you have to update is Vsix/Version. All those date/time tags has no meaning for Visual Studio...(In fact if you update the version number, even without updating the VSIX file, Visual Studio still will trigger an update).
Summary
This is not a really code-article, but the practice described in it makes my life easier on daily basis and I hope you will have the same...
I imagine that is can be very easy to create a small application where the XML will be created/updated from the VSIX files (after all VSIX files are simple zip files), and maybe some-day I will do it, but for today I'm very happy with the manual approach...
