Tag: Visual Studio

Visual Studio 2017 Installer New Features

Visual Studio 2017 Installer New Features

At a high level the installation has been broken down into smaller chunks called workloads. You select which workloads you want to use and only the components required for the selected workloads will be installed. If you want to you can still fall back to the old method of installing individual components. The Visual Studio setup is available as an on-line installer only. You can’t download the ISO from MSDN or the Microsoft website any more. You can create your own off-line installer but more about that later in the post.

The Package Cache

For the installer to work and also perform maintenance tasks like updating and repairing your Visual Studio (VS) installation the VS installer will keep downloaded packages in a package cache. By default the package cache is in:

"%ProgramData%\Microsoft\VisualStudio\Packages"

At the time of writing the ability to disable or move the package cache was in preview, instructions here. Using the VS installer you can disable the package cache but that would have some nasty side affects. Every package the VS installer needs for updating or repairing your installation will be downloaded from the internet and deleted again after the installation is done. You can also specify the location to use for the package cache in the registry. If you create the registry key before you start the installation the VS installer will place the packages in the specified location. For existing installations you have to manually move the packages to the new location.

Creating An Offline Installer

You can create an offline installer using the –layout switch of the VS setup exe:

vs_enterprise.exe --layout c:\vs2017offline [--lang en-US]

The full VS 2017 download is quite large but you can save some space by specifying which language you want to use. By default it will download all of them. Keep in mind the VS installer will download files to your AppData temp folder before moving them to the layout folder. I ran into a problem with one installation where the installer was caching the whole installation in the AppData temp folder on my C: drive even though I was creating the offline installer on a different drive. I was unable to determine the cause but keep that in mind if you don’t have enough free space on your C: drive. To install VS using the offline installer you have to install the certificates used to verify the downloaded packages, instructions here.

Updating The Offline Installer

By default VS will look for updates online even if it was installed from an offline installer but you can force VS to look for updates in the offline installer folder by changing its ChannelURI. You have to edit the response.json file in your offline installer directory and change the ChannelURI value to point to the channelManifest.json file in your offline installer folder, full instructions here.

To update the offline installation folder you can run the VS installer with the
–layout parameter. Pointing it to the existing offline folder, the VS installer will download any new packages to the folder and update the channelManifest.json file. VS installations whose ChannelURI is pointing to the offline installer will pick up the updates from the folder instead of downloading them. At the time of writing the VS installer didn’t purge old packages from the layout folder, it only added new ones so the folder can grow significantly. I guess it makes sense since older VS installations would still need the older packages to repair installations or add features.

Setup Tools

There are also some new tools to detect Visual Studio installations instead of rummaging through the registry.

  • The VSSetup Powershell Module can be installed from the PowerShell gallery using:
Install-Module VSSetup
  • VSWhere exe can be downloaded from the GitHub page here.

Francois Delport
Latest posts by Francois Delport (see all)

Pester Testing And PowerShell Development Workflow

In this post I’m going to have a look at Pester testing and PowerShell development workflow. I’ll be using Visual Studio and Team Foundation Server/Visual Studio Team Services to keep it simple. What I’m going to show won’t be news for developers but this can help to put testing in perspective for non developers.

Developer WorkFlow
Firstly lets have a look at the typical points during development when you want to run your tests and then we will dive into the details of getting it to work.

  • Running tests locally while developing.
    This depends on the development methodology you follow.

    • If you practice TDD you will be writing unit tests as you develop, a few lines at a time.
    • Depending on the size of the script most other developers will be writing a function and then a unit test for it or the whole script and then multiple unit tests. Remember it is better to write the tests while the code is still fresh in your mind.These scenarios work seamlessly if you use Visual Studio with PowerShell tools, Visual Studio will discover your Pester tests and show them in the test explorer.

Side Note: You can also use the tests to make development easier by mocking out infrastructure that is tricky to test like deleting user accounts in AD or deleting VMs.

  • Running tests with a gated checkin. In this case you want VSTS/TFS to run the build and test suite before the code is committed to the main code repository. VSTS/TFS  supports check in policies and one of them requires the build to pass before it is committed.
  • Running the tests after checkin as part of the build process. This is how most developers will run it and although VSTS/TFS doesn’t have native support for Pester tests you can run the tests using a Powershell script. Usually the whole test suite is executed at this point and can include integration tests.

For the last two scenarios to work you have to be able to install the Pester and PSCodeAnalyzer modules as well as any other modules required for your script on the build server. If you are using VSTS hosted build agents this is a bit of a problem since you need administrator access to install modules in the default locations for PowerShell. You can however manually import a module from a local folder during the build process. You can include the modules in you project or store them in a central location or repo and share them between your scripts. Some modules can even be installed from the Marketplace as a build step. If you are hosting your own Visual Studio Agents or using TFS this is not  a problem, you can install them as part of your build server or on demand.

Running A Pester Test
To execute Pester tests you have run a PowerShell script that will call Invoke-Pester. By default Pester will look for all scripts called *.Test.ps1 recursively but you can specify the script to test and even the specific functions in a script. Read the full documentation here.

Retrieving Test Results
Pester can output the test results in NUnit XML consult the documentation for the syntax and output options. VSTS/TFS can display this format on the test results tab. It doesn’t seem to do the same for the CodeCoverage results but you can still attach the output of the code coverage to your build artifacts by using VSTS/TFS commands.

Alternatively you can roll your own test results by passing the -PassThru parameter to Invoke-Pester, this will return the results as a typed object. You can use this to transform the results in any format you want.

Francois Delport
Latest posts by Francois Delport (see all)

Managing Git In Visual Studio 2015

In this last post about Git I’m going to touch on a few odds and ends I came across that are worth mentioning or confused me at first.

Working Directories
Git does not create folders in your local repository for every branch you checkout like TFSVC or SVN does. There’s only one working directory per repository and in that directory is a hidden .git folder where the files are stored.
GitFolder

When you change your active branch by selecting a different branch in Team Explorer, Git retrieves the files for branch into your working folder. If you have changes that were not committed to the local branch Visual Studio will warn you so you don’t loose your work when you switch branches.

Multiple Repositories
When you clone a repository you get everything in the history of that repository and I mean everything, every version of all the file changes that happened since the repository was initialised. This is can be handy since any client repository can be used to recover the server repository should anything happen but it also means the repository can get really big over time.

To keep it manageable you should create multiple repositories in your team project and keep solutions that change together or have a logical reason to be together in a repository.

Keep in mind if you have projects that change together spread across multiple repositories it can add to your headaches, merging and branching and tracking the versions across multiple repositories can be difficult. There are also some practical implications like searching across multiple repositories is not supported by all Git tools.

To create a new repository, open up TFS portal and browse to your team project and click on the Code tab then click on the drop-down arrow next to your current repository name and select Manage Repositories… and click on New Repository.. give the new repository a meaningful name and click on OK.

ManageRepos

AddRepo

Back in Visual Studio, open Team Explorer and click on Manage Connections to see the new repository, right click on it and connect to it.

ManageConnection

Visual Studio will prompt you to clone the repository to start using it.

Merge conflicts in pull requests
In my previous post I discussed pull requests now I’ll briefly show you how to handle merge conflicts. When you submit a pull request to merge your code back into the master branch and there are other changes that can not be automatically merged by Git you will see this error message.

MergeConflict

TFS actually makes it very easy for you to fix it, when you click on the Manual merge help… link under the merge failed message it will show exactly what to do.

MergeHelp

After you do a pull to get the latest changes to your local branches you have to merge master into BranchOfMaster. First make sure your branch is the active branch in Git, then right click on it and select Merge From…, we want to merge from master into this branch.

StartMerge

When Team Explorer shows the Resolve Conflicts section click on the Merge button and you will see the merge editor.
DoMerge

In this case I am going to select both changes and click on the Accept Merge button. Still under the Resolve Conflict section of Team Explorer click on Commit Merge. If you now look at the pull request screen in TFS portal you will see there are no more merge conflicts and you can complete the pull request.

FinishMerge

Remember to pull down the changes to your local master since the pull request only updated the remote/origin master. I assumed when I right click on my remote/origin branches and view the history it would be real time but it seems you have to do a pull to view the latest history as well.

Francois Delport
Latest posts by Francois Delport (see all)

Git Branching In Visual Studio 2015

There are many different ways to use Git or Git workflows, you can even use it like a central repository similar to the way you would use SVN or Team Foundation Version Control but most of the popular and widely used workflows involve branching.

In this post I am going to give a quick demo on how to create a new branch from a remote master in Visual Studio 2015 and submit a pull request to merge it back to the remote master branch. This post is for absolute beginners to Git and follows on the previous post that showed how to create your repository.

In your solution open up Team Explorer and the Branches section. Right click on the master branch in the remote/origin server and click on Create new local branch. Make sure that Track remote branch is NOT selected and give the branch a meaningful name, click Create branch.

CreateBranch

If you look at the Branches section you will see the new FixABug branch created in your local repository but it is not on the server yet. To push the branch to the server, right click on the FixABug branch and click on Publish Branch. If you now look at the remote/origin repository you will see the new branch on the server.

Make some changes to your solution and commit them by opening the Changes section in Team Explorer, give the commit a proper commit message and click on Commit. These changes are now committed to your local repository, sync them to your bug fix branch on the server my doing a sync.

Sync

I did the commit and sync in two separate steps to drive the point home of local repositories but you can use Commit and Sync to do both at once. Next we are going to merge the changes from the FixABug branch that is now on the server with the master branch on the server.

Now we are going to create the pull request. In the Branches section make sure the remote FixABug branch is selected, right click on it and select Create Pull Request and watch the seamless integration between GIT and Visual Studio fall apart as you are taken to the TFS web portal to create the pull request 🙂

CreatePull

In this case I am the same person making the pull request and allowing it but usually the person allowing it will be a senior member of the team that will review the change before allowing it. You can add reviewers to this pull request using the reviewers drop down on the right. I’m going to add myself to the reviewers list.

Review

If I now look under pull requests assigned to me I will see this one waiting. As the only reviewer I am going to approve this pull request.

Approve

Now I will complete the pull request and merge the changes into master by clicking on the Complete pull request button. You will have the option to FixABug delete the branch which can be handy if this bug was fixed and the branch will not be needed anymore. If you now look at the master branch on the server you will see your changes.

This was obviously the happy path, in reality there can be merge conflicts and reviewers can ask for changes and pull requests can be abandoned but I will look at these scenarios in a later post.

Francois Delport
Latest posts by Francois Delport (see all)

Introduction To Git In Team Foundation Server 2015 And Visual Studio 2015

This is short into to using Git in Visual Studio 2015 and Team Foundation Server 2015 it is aimed at someone completely new to Git, like me:)

The most important concept to understand about Git is the fact that it is distributed and works on branches. You will be downloading the code from the remote/origin repository to a local repository on your dev environment. Changes you make to the code will first be committed to this local repository. When you are ready to send your changes up to the remote/origin repository you will first pull down changes made by other users on the remote/origin repository and merge them into your local branch to fix merge conflicts and then you will commit the changes to the remote/origin repository.

Git support is now baked into Visual Studio when you install it remember to select Custom installation and select Git tools as part of your installation.

Installl GIT Tools

Once installed open Team Explorer, in my case I didn’t have any other TFS connections setup. Click on Manage Connections -> Connect to Team Project and add a new TFS server connection.

CreateConnection

Once created, select the server from the list of connections to connect to it. You can ignore the message to configure a workspace, GIT does not use one. Click on the drop down arrow and select Projects and My Teams -> New Team Project… to add a new team project.

AddNewTeamProject

Give your project a meaning full name in this case ‘Trying Out GIT’ and select the process template of your choice.

SelectGIT

Remember to choose Git as your version control system. After a few seconds you will get a success confirmation. You will see the new team project in your list of projects in Team Explorer, double click on it to connect to the project.

Even though the remote repository is empty you still have to clone it your local repository to start working, you will see a message to clone the repository to start working on it, click on Clone and choose a folder for your local repository.

CloneRepo

GIT will download a copy of the empty remote repository to your dev environment. When you make changes and commit them it will first be into this local repository. You will see later how the committed changes are sent to the remote repository on the server.

Since this an empty repository I’m going to add some code to it, click on the New.. button under Solutions to add a new solution to this repository. For this demo I am adding a new ASP.NET MVC application but the type of project is irrelevant. In the team explorer click on Changes and you will see the changes from the solution you created, note the branch is master since you just created it from scratch.

Click on Commit and you will see a successful commit message, each commit gets a SHA-1 hash to uniquely identify it and its changes. This commit was in your local repository, you still have to push it to the server. If you opened TFS web portal and went to the code windows you will see no code in the repository. Click on Sync and you will see the synchronization screen.

Sync

There is quite a bit to explain here:
Sync: Send your local changes to the server and pull down changes from the server and merge them into your local repository.
Fetch: Pull down changes from the server but do not merge them into your local repository, you have to merge them yourself.
Pull: Pull down changes from the server and merge them into your local repository, do not send local changes to the server.
Push: Commit your changes to the server, you may get merge conflicts.

You can see the local outgoing commit waiting to be pushed to the server, press Push to commit the changes to the server. In this case we can safely push since this is the initial commit into master. Normally your changes would be made in a branch and you would submit a pull request to pull your changes into the master branch. The pull request will be reviewed by the person in charge of the master branch and then accepted or declined. I’ll show pull requests and code reviews in my next post.

When push is done select Branches from the team menu to see your master branch on the server.

Origin

Another term you will come across is origin, it means the remote server where the master is. In Visual Studio it will show as remote/origin in other Git tools it will usually just show origin.

Francois Delport
Latest posts by Francois Delport (see all)