I am developing an Isolated Shell that caters to "designers/special content creators" performing specific tasks, using the Shell. As they operate on files, they need to be able to use TFS for source control. This is mainly due to the fact that Developers will also operate on the same files from TFS but using Visual studio 2008.
After looking and searching I still could not find Team Explorer to be available to Shell.
Asking on MSDN forums, lead me to the answer that "this is not supported yet in the Isolated Shell". Well, then the whole point of giving away a shell is not justified, if you want to use a source control system for your files. The idea is not to recreate everything and develop tool windows etc using the TFS provider API.
The Visual Studio Extensibility book by Keyven Nayyeri has an example, which only goes so far into this problem of adding a sc provider.
Has anyone worked on developing Visual Studio 2008 Isolated Shell applications/environment? Please provide comments, questions - anything that you have to share apart from the following threads, which I've already participated in.
Threads from MSDN forums:
Team Explorer for Isolated Shell
Is it possible to use Team Explorer in VS Shell Isolated?
Thanks for your answer. Yes you are right, we will acquire CALs for users without having to buy them Visual Studio, that's the direction we will be taking.
But I am yet to figure out how to make Team Explorer available to such users, inside Shell. So I am looking to find out the technical details of how that can be done.
I mean, I have a user, he installs my VS Shell application, he has no VStudio Team system on his machine. Now if I acquire CAL for TFS and install Team Explorer, do you think it will be automatically available in the VS Shell app?
Any ideas? have you worked on making this happen?
Thanks
It sounds like you are trying to allow the "special content creators" save files in TFS Source Control without having to buy them a license to a Visual Studio Team Edition -- correct me if I'm wrong.
If that's the case, unfortunately I believe that you can't quite do that. Your users still need a Client Access License ("CAL") to access TFS.
I think that you can acquire just CALs for your users without having to buy Visual Studio for them (I presume for less than a full blown Visual Studio would cost). At that point, you can just distribute to them the Team Explorer, which is a VS shell with nothing but TFS access components. That is available in your TFS server media.
I found this via Google. You might want to review it to decide your best options:
Visual Studio Team System 2008 Licensing White Paper
The only exception to the CAL rules I'm aware of is access to Work Items. Assuming properly licensed servers, anyone in your organization can create new Work Items or view and update existing ones created by them, using the Work Item Web Access component.
Just stumbled on this question, it might still be relevant to you.
You have the option of including the AnkhSVN (http://ankhsvn.open.collab.net/) packages and load it into your Isolated Shell. While there are some issues around it, with Subversion support, you could use SvnBridge to access TFS repositories. This might bring you a little bit closer to the process you are trying to achieve.
Related
How do I view and integrate with GitHub issues using Visual Studio 2022?
When connected to an Azure Repo, the VS Team Explorer window includes a "Work Items" view that shows open issues from Azure Boards. I can easily create a branch from one, link it automatically, and submit pull requests. The integration is great.
When I connect to a GitHub repository, that integration is lost. The Team Explorer window no longer contains a "Work Items" view. Since I can't view the issues, I can no longer automatically create branches that are linked to the issue. I have to now manually type in the issue number if I want to link a commit to the issue. And the "Create Pull Request" menu items simply launches the browser to the GitHub page; there's no integration there, either.
I have found a VS Code blog post that enables a lot of this functionality (and more) into VS Code, but I've yet to find anything for Visual Studio 2022. From that post, I am most interested in the "Working on issues" bit. As described above, this was functionality that worked with Azure Repos but is lost with GitHub integration. How might I regain that functionality with GitHub and Visual Studio 2022?
The "old" team explorer did a number of really nice things, but it was also very hard to integrate into for other tool vendors. With the new Git experience the Visual Studio team opted for a more agnostic approach.
The old Team Explorer was written in .NET 4 and was very much geared towards integrating with Azure DevOps. It stems from 2005 when Team Foundation Server first got released. Over time other vendors snuck their way into Team Explorer, but mostly through undocumented and unsupported ways. This has caused many interesting issues in the past. The concept of the Team Explorer window also wasn't ideal for hosting GitHub, Azure DevOps, BitBucket and every other tool-vendor that wanted to be listed and there was very little in the way of control for users to set the order of elements or hide certain tiles. As such it's a breeding ground for bugs and it needed to be ported to .NET Core and x64 and to support out-of-process extensibility to properly support Visual Studio 2022 anyway.
So Team Explorer and its old undocumented extensibility points were dropped and the new Git Window was born. This window is a pure git client and it's vendor agnostic. Vendors may add menu items to the top level menu, but they currently can't extend the new git window.
At the same time, Visual Studio 2022 dropped support for the built-in browser window, which was a memory hog, loads IE11 and also needed full retooling to support the x64 out-of-process loading that Visual Studio 2022 now demands.
All of this work now allows Visual Studio to use more memory, it's faster and by moving extensions out-of-process, it has greatly improved the performance and stability of the visual studio platform. Unfortunately this all happened at the expense of some features.
The new git experience is no longer constrained by the Team Explorer window, is a top-level citizen in Visual Studio and can finally use easier to remember keyboard shortcut keys. It's much faster too and the new architecture allowed the team to build interactive rebase, multi-repo support, submodule support and more. But their priorities have been in advanced git scenarios for a long while, not in building support for vendor specific issue integration. It looks like that may be changing though. Auto-completion of #... is now in Visual Studio 17.5 preview:
Some tool vendors may invest in native integration into Visual Studio in the future. Many old extensions are no longer available in VS2022 or the authors are still working on a new version that conforms to the new requirements.
On the other hand you have VS Code, which is used by GitHub itself internally, runs in a browser, powers github.dev and github codespaces and doesn't carry the legacy if Visual Studio 2022. It's not Microsoft, but GitHub who has extended vscode and they added the support for their platform through extensions and open source contribution to the editor directly. GitHub has a different stake in vscode, they have the engineering staff that knows how to extend atom-based applications (they basically built that technology) thus, their features have been added to vscode.
Is it fair? Do we want it in big VS as well? Sure, but unfortunately, that's currently not where the money is being spent.
There are a few ways to accomplish what you want. But none are exactly what you desire.
The web
The main way is to start working from the browser. On every issue there is a Development section from which you can create a branch or initiate a pull request from the associated branch:
You can then immediately check it out locally
Or navigate to the code panel for the branch and click the open in visual studio link. This will launch visual studio in the correct context using the repo you selected and will check out the branch locally for you to start working.
Any commits you make to this branch are automatically associated to the issue, so there's no need to pass in the #issuenumber every time.
The cli
An alternative to working from the browser is to use the CLI. If you have the GitHub CLI installed it will pick up the context of your repo from the list of remotes and you can perform quick commands straight from visual studio's built-in terminal.
gh pr create
to create a new PR.
gh issue list
to quickly list your open issues
gh issue develop #issuenumber
to create a branch on the remote, associate it to your issue and check out the branch locally.
It takes a bit of getting used to the commands, but if you like the CLI it's a quick way to work.
In Visual Studio
You can create pull requests from your current state, which will then bring you to the browser with most of the data pre-filled. Issue auto-completion also works in the browser from that point forward.
To get the other features you want, you must install extensions. Unfortunately, GitHub has stopped development on the old GitHub for Visual Studio extension since most of its features have now moved into visual studio. It's not easy to build and maintain an extension for multiple versions of Visual Studio, so I don't expect this will be brought back to life.
I rely on the Git Web links extension to quickly switch between web and visual studio from the context of my working files:
In the settings you can set the default behavior to not copy, but to open in browser.
Other functionality you're after is currently not available through a publicly listed extension. Most of there features have also been removed or deprecated for Azure DevOps itself, so I don't expect the Visual Studio team to be in a hurry to add first-class support for Issue tracking back in.
Unfortunately, the "Work Items" view and the related issue integration for GitHub Repos is not currently available in Visual Studio 2022 out of the box.
You might be able to find a Visual Studio extension that provides this functionality, but I'm not aware of any off the top of my head.
An alternative option would be to use the GitHub API to retrieve the issues, and create a custom extension to display the issues in Visual Studio 2022. However, this would require custom development work on your part.
It seems like the VS2022 will have this feature in future (it's in Preview now).
https://youtu.be/0NiHvdoMBO8?t=95 [VS2022 Preview Feature]
I'm sure this is a common problem, but I can't find much info about it.
Problem
I have a work computer, a home computer, a surface, and maybe some Azure VMs that i'd like my visual studio 2013 extensions synced across them. I seem to have to refresh/wipe a computer fairly often, and re-installing all the extensions I like to use is sort of a pain. I initally thought the new VS Profiles would do this, but apparently they only sync themes/general settings.
Attempted/Outdated Solutions
There used to be an extenstion that apparently did this
Extension Sync
But that looks like it's only for VS 2010. There was also a blog post that showed the location that the extensions were saved in.
http://www.larswilhelmsen.com/2012/01/08/syncing-visual-studio-extensions-and-settings-with-dropbox/
Which looked like a perfect solution, except in 2013/2013 the extensions location must have changed, and I cannot find them.
Question
Does anyone know how I could sync my extensions across multiple machines? Or possibly know the location that the Extensions are stored in and if it's possible to change that location to something like Dropbox/Skydrive/Google Drive?
If you've upgraded to Visual Studio 2015 there's a new extension that Microsoft just released for it called the Roaming Extension Manager.
It sounds like this is what you are looking for.
https://visualstudiogallery.msdn.microsoft.com/7b421a95-c32c-4433-a2be-a41b276013ab?SRC=Home
There's something called the "User State Migration Tool" that is intended for preserving state in corporate PC desktop deployments for wipe-and-load, similar to your Azure scenario.
If you know something about the way the extension settings are saved (as shown in the blog), it's not too hard to construct an XML descriptor and use the deployment tool to apply the settings. The tool is command line so it is easily automated.
http://technet.microsoft.com/en-us/library/hh825142.aspx
This solution has increasing value when you have more than just Visual Studio to migrate into your VM.
there is new Extention for Visual Studio 2022 there which allow to import/export
Extension Manager
We're looking into migrating to TFS 2010 in the next few weeks. However, we're unclear on what kind of tools are required for the team. We know developers need Visual Studio but what tooling is required for Project Managers and Testers that will ONLY need to manage work items? Do they also need Visual Studio to just view and edit work items?
Project Managers and Testers can use the following methods to access TFS 2010
The web access portal - this allows the ability to create/run queries of work items, and even view source/builds if they want
Excel/Project - Both have integrate with TFS. You are able to load work items directly into Excel/Project, edit them, and publish them back to TFS.
Visual Studio with Team Explorer only - This is a barebones installation of VS, with the Team Explorer only. It doesn't take all that long to install, but it will say "Visual Studio" when launched. Not sure if that is scary to testers/project managers.
Web access provides a good complete set of functionality, but having VS/Team Explorer will provide a rich client experience (read: faster, more responsive).
Additionally, in order to get the Excel/Project integration, you'll need at least the VS/Team Explorer installed on the client box, even if they never use VS. And you need a CAL (Client Access License) to use the web access portal.
So to summarize, TFS provides a lot of ways for the non-developer to interact with the system, but all of them require a CAL, and most of them require installing VS/Team Explorer on the client machine.
In short, they don't need Visual Studio. They can use Team System Web Access (formerly known as TFS Web Access) to do pretty much everything a developer can do, except associate a check-in with a work item. After you install TFS 2010, you simply browse to http://yourserver:8080/Tfs/web and you're in!
Project Managers (and all other team members) can also work with work items from Outlook using 3rd party TFS client embedded in Outlook: TeamCompanion www.teamcompanion.com. This way, assuming they otherwise use Outlook, they wouldn't need to change tools or use any additional tools at all.
As is the case with Excel or Project integration they would still need a TFS CAL and additionally a TeamCompanion license.
TeamCompanion supports much more than just work item management: Email/TFS integration, SQL Server Reports, SharePoint document integration and much more...
Full Disclosure: I am the Product Owner of TeamCompanon, so I may be biased :-).
There is a web front end which you can use to manage the work items. There is also integration to Excel and MS Project.
See http://msdn.microsoft.com/en-us/library/ms181304.aspx for more information on Team Foundation Clients
I am. And I am wondering if there is any good reason to use professional .. Also for hobbiest programming...
So far the only thing I have missed is being able open certain .sln files that use testing projects and more advanced things.. but that not that big of a deal.. though I do miss testing
I was first surprised that the small consulting company I am working at does not use a paid edition of VS2010 (and SVN instead of TFS and Open Office instead of MS Office)
Anyone else working at a place like this? With the new Platform installer I like how I can get a new machine running and easily check and install what I need for free so that makes it even easier.
There's one good reason: Microsoft does not allow 3rd party extensibility in Express. Plug-ins like ReSharper add significant value to Visual Studio. I have trouble imagining doing professional work in a timely manner without them.
Our company is considering using the Visual Studio Shell for one of our products.
Does anyone have any experience using it? Was it easy to work with? Did it save time? Are there any things that you weren't able to get it to do? Have you shipped anything with it?
A couple of points regarding the Isolated shell.
As you might know, there are two considerations when you use shell - Isolated Mode and Integrated Mode. (Read more from MSDN)
Isolated Shell can be used by organizations, to build applications that run side by side with other editions of Visual Studio.
Here are some points we learned,
trying to use shell for some of our
applications.
If you are planning to use Isolated
shell, you can't use Microsoft
Language Packages like C# and VB.NET
inside that.
Creating a package for your shell is
much like creating any other VS
Package.
You don't have support for Team
Explorer and VS Built in Source
Control access, in Isolated Shell
(See this post from Vin)
Though not directly related - If you are using VS SDK 1.1 to develop your packages - remember that the managed package framework is no longer available with the default distribution. So don't get surprised if your old packages can't load MPF files after moving to SDK 1.1. It has got moved to Codeplex as a separate download.
I played around a bit with it a couple of weeks ago, like every thing there is going to be a learn curve but if you study the examples a bit and have a look at a project on codeplex called Storyboard designer. I'm sure that you could pick it up, I found it very hard to find other examples on the net but I wasn't looking very hard.
I would say if you think that the shell can give you want you need I would go for it, it is a very handy interface to work with and if your targeting developers it is also a common interface for them, so it will feel natural.
I typically use Visual Studio Community on my PC for developing business intelligence solutions (databases, SSIS, SSAS, SSRS), then deploying to the server. A few weeks ago my managers requested we put Visual Studio on a server so that other developers and consultants could connect to the server and access Visual Studio.
Ultimately I installed SQL Server Data Tools (14.0.61021.0), which automatically installed Visual Studio Shell 2015. After installation, I launched Visual Studio Shell and tried doing some of the things I am used to doing in Community edition. I was able to do pretty much anything I was used to doing for BI Development.
Visual Studio Shell 2015:
Solution files with BI projects...
SSIS
Installing extensions & add-ons...
ANKHSVN for version control with SVN server
Visual Studio 2015 Color Theme Editor
Project deployment