Collapse all functions in Visual Studio 2015

Hold down CTRL, and press M and then O.  In the code view, all functions will collapse.

Visual Studio Solution Explorer Collapse All

When dealing with complex visual studio solutions with many projects, the solution explorer can become a mess of opened folders and files.  Solution Explorer remembers which folders you have opened, so if you're like me, you never go back and close the folders once you're done.  You just want to collapse the entire tree structure occasionally.  By default, you can collapse the current node of a tree by pressing the - sign on the number keypad.  But this only collapses the current node, and does not recursively close every sub folder.

This command does exist in Visual Studio, but it is not in the menu at least in the 2015 version that I have.  To use it, you have to assign a keyboard shortcut to it by going to the Tools menu and selecting Options, and then Keyboard like so:

Here I've set up a shortcut, so if I hold down CTRL while pressing CO, it will recursively collapse the current node in Solution Explorer.

UPDATE:  Don't use CTRL C as a starting sequence for your chord.  This will mess up the old standard CTRL C for Copy.  I ended up using CTRL O.

Favorite Visual Studio Options

I recently upgraded to Visual Studio 2015, and had to set it up to my liking.  Since I only upgrade about every 2 years or so, I always forget where these settings are.  So, today, I'm going to make a note of these settings:

Using layer diagrams to validate your architecture

A problem with solutions that have a more sophisticated architecture is ensuring that developers adhere to the design.  It's pretty easy for a developer to inadvertently (or on purpose) ignore the system design and code it "just so it works".  One of the tools you can use to combat this is using a layer diagram in Visual Studio 2013 to validate your architecture.  This works best when adopting this from the very beginning of a project.

1. Add a project using the Modeling Project template.  
2. From the Architecture menu, choose New Diagram.
3. Choose Layer Diagram.
4. You can drag "stuff" from both the Architecture Explorer as well as Solution Explorer.
5. Each time you drag something to the diagram, you create a "layer" for that "artifact".
6. I tend to group likewise classes into namespaces, so dragging namespaces from the Architecture Explorer works well for me.
7. To create higher-level (project level) layers, instead of dragging the project into the diagram, it works better to create your own generic layer that is not tied to any code, and then dragging the namespace layers into your generic layers.
8. You can also drag individual classes from Solution Explorer onto the diagram.
9. Once you have all your layers defined, then select all of the layers, right click, and choose Generate Dependencies.
10. At this point, if you right click in some white space and choose Validate Architecture, you should validate fine.
11. If anyone goes rogue and violates your architecture, then Validate Architecture will fail and direct you to the offending code.

Removing a stubborn assembly from the GAC

Sometimes when removing a assembly from the GAC, you will get an access denied message.  In this case, you'll need to use the gacutil utility to remove the file.  This is installed as part of Visual Studio and can be accessed by opening a Visual Studio Command Prompt.  If the computer you are working with does not have Visual Studio installed, you can copy the tool from a computer that does.  Just stick it in the framework folder:  C:\Windows\Microsoft.NET\Framework\v....

Here is the command to remove the file:

gacutil -u NameOfFileGoesHereWithoutTheExtension

Add an existing solution to TFS 2013

This post assumes you have a TFS server configured.

First you will need to create a TFS project to hold your files.

1. In Visual Studio 2013, Team Explorer, click the navigation drop down bar and select Projects and My Teams and then choose Add New Project.  You may need to be a collection administrator to do this.  Browse here https://<TFS Server>/tfs/<Collection Name>/_admin to add a user to this group.
2. A wizard will appear that will walk you through all of the options.
3. The most important option here (and the most difficult to understand) is choosing the process template.  Essentially, you are choosing what application lifecycle management style you use while developing software.  I chose Scrum because it's something that I'm interested in and it's the default choice.
4. You'll also need to choose a version control system, Git or TFVC.  With Git the repositories are stored locally and with TFVC, there is a single version of the truth on the server.  TFVC seems more appropriate if you're going to have a full blown TFS server.

Next, add your solution to the new project.

1. If you don't know your branching needs yet, then don't create them at this point.  However, more than likely at some point, you will want to create branches.  To prepare for this possibility always put your initial files into a folder called Main.
2. Map the new project to a local workspace.
3. In Source Control Explorer, right click the project, and choose New Folder and call it Main.
4. Check in this new folder.
5. In File Explorer, copy your code into the Main folder in your workspace.
6. In VS, open your solution from the Main folder in your workspace.
7. Right-click the solution, and choose Add Solution to Source Control.
8. Then Check In everything and you're done.

http://msdn.microsoft.com/en-us/library/vstudio/ms181384.aspx

TFS Cache

The other day I connected to a test TFS server that was identical to the production TFS server using Visual Studio 2013.  When I tried to connect back to the production TFS server, I got a 404 error.  To fix the problem, I closed Visual Studio and cleared this folder:

C:\Users\<You>\AppData\Local\Microsoft\Team Foundation\5.0\Cache

Publishing Web Applications using Visual Studio

"Publishing" a web application means preparing the application into a state from which it can be "deployed" to the web server.  For me, this has always been two distinct processes, but Visual Studio has some publishing options that allow you to deploy to a web server as part of the publishing process.

You have 4 "publish methods" to choose from when you right click a web application project and select Publish.  FTP, File System, Web Deploy, and Web Deploy Package.

File System

Here you are simply choosing a folder and when you click Publish, the files will be placed in this folder.  You can then copy these files into the physical directory of the site.

FTP

Same idea as above except you are selecting a folder on another computer.

Web Deploy

This is also known as One-Click Publishing.  You simply specify the server name and the site, and Visual Studio will deploy the site for you when you publish.  Specify the Destination URL field if you want the default browser to open up with this address when publishing and deployment is complete. Keep in mind that the server you are deploying to must support Web Deploy.  Here are the instructions to set up a web server to support Web Deploy:

1. Download and install Web Deploy 3.5.  (This assumes you are publishing using Visual Studio 2013).  During installation, be sure to click Custom and choose to install all the features available.
2. Open up IIS, and click the root server node in the tree view on the left.
3. Select Management Service.
4. The options will be grayed out if the Web Management Service is running.  Stop the service, and be sure to check the "Enable remote connections" checkbox.
5. In addition you may need to add your development machine's IP address to the box at the bottom.
6. You might also need to open a firewall port (8172 by default), on the server.

Web Deploy Package

Same idea as Web Deploy except a package is created instead of Visual Studio deploying the application for you.  A package is simply a zip file that contains the published application files that you would also see if you selected the File System option.  However, the package can be imported using IIS with a nifty wizard.

Web deploy packages allow you to set some runtime parameters for the web.config file.  If there is a value that the developer does not know at compile time (like a password), the administrator will be prompted for the value when he imports the web deploy package.  Simply add a file called parameters.xml to the project directory in Visual Studio and put something like this in there:

<parameters>
  <parameter name="Test Key 1 Entry" 
             description="Specifies what environment you are in."
             defaultValue="Development" tags="">
    <parameterEntry kind="XmlFile"
                    scope="\\Web.config$"
                    match="//appSettings/add[@key='TestKey1']/@value">
    </parameterEntry>
  </parameter>
</parameters>

The parameter node describes what it will look like in the IIS wizard when you import the package.  The parameterEntry node describes how to update the file.  The scope attribute defines the file to update, and the match attribute represents an XPath that selects the attribute and node to update.

A note on transforming web.config files

When you do know the web.config settings for various environments at compile time, you transform web.config files.  Essentially this means modifying the web.config that gets published based on the build configuration.  Instructions for doing this is beyond the scope of this post.

ASP.NET IIS Registration Tool (aspnet_regiis.exe)

Let's say you install a new version of Visual Studio which also installs a new version of the .NET Framework.  If you are using IIS (not IIS Express) on your local PC to host a site you are developing, it won't work until you register the new version of the framework with IIS by using the registration tool.  The tool exists in each version of the frameworks folder.  Just browse to the folder of the framework you want to register and run the tool with the -i option.

Open a Command Prompt as an administrator.

cd C:\Windows\Microsoft.NET\Framework64\v4.0.30319 for example.

Then, aspnet_regiis.exe -i

MS info on tool

Debug .NET web applications without timing out

This happens when you are hosting the web application in IIS.  Just open up IIS, click on the application pool and go to Advanced Settings.  Set Ping Enabled to False.  Apparently IIS pings itself occasionally and if it doesn't get a response, then it shuts down.  Keep in mind that while you are debugging, IIS is blocking all other requests, so it sees this as a bad thing.  So turning this behavior off during development is fine.