Visual Studio Behind Corporate Firewall

Developing in companies that have proxy servers for developers can be frustrating in this age when every tool needs access to online resources and even parts of software development life cycle are cloud based. Proxy servers that require NTLM authentication are one of sources of frustration. NTLM is developed by Microsoft but many applications built by Microsoft do not support it or require some configuration and in worst cases some hacking to make it work. Below are the list of some the tools that developers might be using on a daily basis. I keep adding more to the list as I encounter them.

Visual Studio Code (VSCode)

VSCode 1.15 and up now supports NTLM proxy (finally Microsoft supported its own authentication protocol).

NPM

For NPM you have two options. Either to send proxy address and credentials in every single command you run or to set them in the global configuration of NPM. I recommend the former because it is more secure.

Set proxy in every command

When calling NPM command you can always use --proxy switch to set proxy for each command. The syntax for using this switch is the following.

--proxy username:password@proxyaddress:port

For example to use myproxy:8080 as proxy address and my-domain\reza as username and P@ssw0rd as password when calling the install command you can type the following.

npm install --proxy http://my-domain%5Creza:P%40ssw0rd@myproxy:8080

Please note that both username and password are URL encoded. You can use the following command in your browser’s developer tools to encode them.

encodeURI('my-domain\\reza')
encodeURI('P@ssw0rd')

Set proxy in NPM configuration

To set the proxy in the global configuration of NPM you need use the same format as above for sending the proxy address, username and password and use npm config set to store it in the configuration. For example to set the proxy address to myproxy:8080 and username to my-domain\reza and password to P@ssw0rd you can use the following command.

npm config set proxy http://my-domain%5Creza:P%40ssword@myproxy:8080

Visual Studio, Web Platform Installer and other .NET applications

To set the proxy for pretty much any .NET application, you need to put the following in the configuration file of that application.

<system.net>
    <defaultProxy useDefaultCredentials="true" enabled="true">
        <proxy bypassonlocal="true" proxyaddress="http://myproxy:8080" />
    </defaultProxy>
</system.net>

For Visual Studio I suggest also enabling IPV6 if the above configuration did not work as suggested by some other developers.

<system.net>
    <settings>
        <ipv6 enabled="true"/>
    </settings>
    <defaultProxy useDefaultCredentials="true" enabled="true">
        <proxy bypassonlocal="true" proxyaddress="http://myproxy:8080" />
    </defaultProxy>
</system.net>

For executable files the configuration file is named the same as executable’s file name but with .exe.config extension. For Visual Studio it is called devenv.exe.config and for Web Platform Installer it is WebPlatformInstaller.exe.config.

Advertisements
Visual Studio Behind Corporate Firewall

Disabling Security warning for Attach to process in Visual Studio 2010, 2013 and 2015

You probably have already suffered from the pain of having to click one more time when attaching visual studio’s debugger to a process. As developers we all have the obsession to be more productive and everything that comes in the way is a bummer. I should have shared this little secret before, but … I forgot.

You know this message box, right?

attach-security-warning1

Now when a colleague sent me a link to a blog post that explains how to change a registry key to disable the security warning in Visual Studio when attaching to processes, I decided to write a little “.reg” file to make it even easier for you. This warning is there to warn you when you are attaching the debugger to a process and that process is (that are running with different accounts than the one running Visual Studio)  The reg file works for Visual Studio 2010, 2013 and 2015 no matter which edition. You can view / download it from here:

Disabling Security warning for Attach to process in Visual Studio 2010, 2013 and 2015

Per developer web.config files using out-of-the-box Visual Studio functionality

It might be a repetitive subject and some might argue that it’s even best to have identical web.config files for all developer. But, the fact it sometimes it’s inevitable! you are not always building software from scratch. It might be an extension to a huge software that contains per-machine keys and configurations. Unfortunately there are many blog posts here and there that suggest using batch files and methods that are more like a hack. Here I’m going to explain how to use the out-of-the-box functionality in Visual Studio without any external tool or hack.

If you already know how those two web.debug.config and web.release.config files work you’ll get the idea. Basically they are a kind of Xslt transformation that are selected based on the current configuration (web.($configuration).config) and we want the same thing but based on current username (web.($Username).config). To learn how to use web.config transformations and its syntax visit “http://go.microsoft.com/fwlink/?LinkId=125889

And here is the recipe:

  1. Right-click over the project name in Solution Explorer and select “Add \ New Item…”
  2. Select XML File under Data category and give it a name in the following pattern web.{username}.config (e.g. web.reza.config).
  3. Copy-paste the content of web.debug.config to this new file (i.e. web.{username}.config) to use as a starting point and override the settings as you need. If you don’t feel comfortable with the transformation syntax, take a look at this page. It’s fairly easy.

Here is an example to override the <machineKey> attributes.

<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <system.web>
    <machineKey xdt:Transform="SetAttributes" validationKey="EFEF01678000A361AADF4E01DB5AD356C91111E781660310" decryptionKey="6EF12ECA1A36ACAC4D08212E9FA8F34B1919A3DD818B8E0F" validation="SHA1" />
</configuration>
  1. Save the file.
  2. Right-click over the project name in Solution Explorer and select Unload Project.
  3. Right-click again over the project name and this time select Edit {projectfilename}.
  4. At the end of the file, right before </Project>, paste the following piece of XML (don’t worry I will explain later).
<Target Name="AfterBuild" Condition="Exists('web.$(USERNAME).config')">
    <Copy SourceFiles="web.config" DestinationFiles="obj\$(Configuration)\tempweb.config" />
    <TransformXml Source="obj\$(Configuration)\tempweb.config" Transform="web.$(USERNAME).config" Destination="obj\$(Configuration)\tempweb2.config" />
    <ReadLinesFromFile File="obj\$(Configuration)\tempweb2.config">
      <Output TaskParameter="Lines" ItemName="TransformedWebConfig" />
    </ReadLinesFromFile>
    <ReadLinesFromFile File="web.config">
      <Output TaskParameter="Lines" ItemName="UnTransformedWebConfig" />
    </ReadLinesFromFile>
    <Copy Condition=" @(UnTransformedWebConfig) != @(TransformedWebConfig) " SourceFiles="obj\$(Configuration)\tempweb2.config" DestinationFiles="web.config" OverwriteReadOnlyFiles="True" />
  </Target>
  1. Save the project file.
  2. Right-click on the project file again and select Reload Project this time.
  3. Build and project and check the result.

And now the explanation. Basically what we did was to add an AfterBuild process (you can also use a BeforeBuild) and set a condition for it to only run when there is web.{username}.config file in the project’s root. It means that if there is no such file for the current developer, it will be skipped. Within the process we have 5 actions that run in the order that is written:

  • <Copy> makes a copy of web.config file to “obj\($configuration)” folder with the name “tempweb.config”. The value of $Configuration depends on the build configuration currently selected in your Visual Studio (e.g. Release or Debug).
  • <TransformXml> runs the transformation to override developer specific values in the tempweb.config file and generates another file (tempweb2.config).
  • The two <ReadLinesFromFile> actions load the content of tempweb2.config and original web.config file into two different variables.
  • The last <Copy> replaces the original web.config only if there is any difference between the generated file and the original (Condition="@(UnTransformedWebConfig) != @(TransformedWebConfig)").
Per developer web.config files using out-of-the-box Visual Studio functionality