New Visual Studio 2013 Features for TypeScript

New Visual Studio 2013 Features for TypeScript

  • Comments 37

As users expect more from the web – more features, more device support, more interactivity – ASP.NET developers are increasingly building large JavaScript applications. Starting with 0.9.1, a key focus for TypeScript's capabilities in the Visual Studio support is enabling TypeScript to work better with ASP.NET projects.

Adding TypeScript to a Project

To get started with TypeScript in an ASP.NET project, just add a TypeScript file by choosing Add – TypeScript File in the Solution Explorer right click menu, or by using the Add – New Item dialog. Adding a TypeScript file automatically onfigures the project to support compiling TypeScript. You can also rename JavaScript files with the “.ts” extension to convert them into TypeScript files. Since TypeScript is a superset of JavaScript, you can gradually migrate the scripts you already have by adding type annotations and restructuring the code to use classes, interfaces, and modules.

Adding Declaration Files

One of the best parts of JavaScript development is the wealth of useful, free libraries available online. To use these JavaScript libraries seamlessly in TypeScript apps, TypeScript supports declaration files (with the extension “.d.ts”) that describe the types of objects in JavaScript files. Through the community efforts, many popular JavaScript libraries now have tooling and error detection using these declaration files.  Sites like DefinitelyTyped have become indispensable for developers by collecting these declaration files together in one place.  Contributions by the community have mirrored these packages as NuGet, making them available to Visual Studio users.

In 0.9.1, with a right click you can now choose “Search for TypeScript Typings…” This searches NuGet for TypeScript-related packages matching the name of the JavaScript file. If you install a typing package, it will automatically be referenced by all of the TypeScript files in your project. You no longer need to explicitly add reference tags in your TypeScript code to each of the declaration files.



TypeScript 0.9.1 continues to make it easy to debug TypeScript code, letting you focus on the code you've written. Because the TypeScript compiler generates source map files that relate the symbols in your TypeScript code with its JavaScript output, you can set a breakpoint in a TypeScript file, open your app in Internet Explorer, and then step through your code in Visual Studio just like ordinary JavaScript. You can examine the values of objects, add watches, view the call stack, and more. Since TypeScript is compiled to clean, readable JavaScript, it’s also straightforward to debug your code in your browser’s developer tools.

Organizing TypeScript and JavaScript in Solutions

By default, TypeScript files are automatically compiled when they’re saved and when your solution builds. Generated JavaScript files are placed in the same directory as their TypeScript source files. Think of the generated JavaScript files like DLLs generated from C# or VB code: they’re not included in your project, so they don’t appear in the Solution Explorer. If you want to view the JavaScript files, you can use the “Show All Files” button at the top of the Solution Explorer. The TypeScript Playground is another great tool for quickly seeing how your TypeScript will be compiled.

Other Editors

We’ve released the TypeScript compiler and language as open source to make it easy for the community to build great tools. While we think Visual Studio 2013 provides the best TypeScript development experience, there are a number of other editors with TypeScript support available, including Eclipse, Web Storm, Sublime Text, emacs, and vim.

We hope that these features make it seamless to use TypeScript in ASP.NET projects in Visual Studio 2013. As always, send us feedback on the TypeScript CodePlex page.

Leave a Comment
  • Please add 8 and 2 and type the answer here:
  • Post
  • The adding TypeScript to a project section doesn't seem to work on Windows Store App projects unfortunately :(

    There's no "TypeScript file" available in the "New Item..." menu.

  • I really enjoy the new debugging features and the typing integration.  The only thing I truly miss from Web Essentials was the split-screen editor support.  While I can manually take the .ts file and split the screen with the .js file, you always get the prompt to "reload file from disk" which slows things down.  When doing user groups, offering training and evangelizing TypeScript, the split-screen view is what really sold people and help them understand what's going on.  Hopefully either the VS team or Mads can add back the split-screen feature because I sorely miss it.  Right now I'm looking at rolling back to VS 2012 for demos.

  • Mads Kristensen is the guy behind Web Essentials plugin and the Program Manager at the Microsoft Web Platform.

  • @Craig - we currently don't have Windows Store application support in place, but that is definitely on our radar.

    @Sid - I believe you can turn off that warning using the "Auto-load changes, if saved" checkbox under Tools/Options/Environment/Documents.

  • @Gary B

    Right, if you want to use the old style of projects, you would need to set up the project in the way earlier versions did it.  The newer style is the one we're planning to support going forward, as it's simpler and more flexible to not treat the .js file(s) as part of the project.  No doubt this will evolve as we support more styles of JS projects.

    For ASP.NET projects, you can also create a normal ASP.NET web application project (not a website project), and when you add a TypeScript file to it, we will automatically update the project to build the TypeScript.  This lightweight style of upgrade will probably be how we go forward, so you don't have to worry as much about editing projects manually.  

    As for publishing, it's my understanding in talking with the dev who worked on this that the .js files generated by the msbuild step should be included as part of the publish.  This should go for both the HTML Application and the ASP.NET web application projects that are updated with TypeScript.  If there are situations you're finding where this isn't the case, please let us know via the issue tracker:

  • We are using Typescript in production code since version 0.8 and we found following solution as the most practicable.

    The generated .js and map Files are included in the project but are not included in the source control, because the compiler and the automated build is not supposed to check out and change files on every build.

    The problem is also mentioned here:

  • Great product!  Love using it for Dynamics CRM development, and look forward to the 1.0 milestone!

  • Hi Jonathan, having an issue with the .js output files. They get created whenever I save/build my project but they are not included when I deploy my application (using web deploy for example). Is this a known problem? The typescript files under my project are listed as follows:

    <TypeScriptCompile Include="TypeScript\Map.ts" />

    I'm using VS2012 with the default project settings.


  • Since nesting support is broken (at least for me) in vs 2013. The following plugin has saved my life:

    I don't understand why this was removed. I don't see any other option for keeping folders clean of .js/ files while also including them in deployments via Publish without any special workflow.

  • Thanks Vaz, that will do the trick until they figure this out. I found out that the generated .js files are included in the bin/Release folder when publishing but that's totally useless

  • To Jonathan Turner:

    Our company's commercial application consists of an ASP.NET web site, and it is not practical to convert it to a web application.  We have begun using TypeScript in a limited fashion, but need the following features:

    - Compile to ES3 since we have many users still on IE 8.  Since we have no .csproj file, where can this be configured?

    - Create .map files so we can debug in .ts files.

    - Add .ts files to the project with the context menu.

    - Have .d.ts files work for all .ts files - currently we have to add /// <reference path... for each one.

    Will "web sites" in Visual Studio gain full TypeScript support in the future?  

    Is there any current workaround for the ES3 or other issues?


  • @Tim Ammons -  To my understanding, the "web site" project works differently than the web application in that there is no build step.  Without it, we can't add the TypeScript compile step.  That said, I think this is something we'd like to get working in the future.

    If you have an app that does build, you can open up the project file and set the settings in the XML to configure the output.

    For example, here is what I see for the current project I'm working on:

     <PropertyGroup Condition="'$(Configuration)' == 'Debug'">





    That XML configures the TypeScript build.  You can also see it set the TypeScriptTarget.  You can change this to ES3.  The ES3 and ES5 targets are very similar, with one of the only exceptions being that you can't use getters/setters in classes in ES3 because ES5 features are needed in the code generation.

  • @Jonathan Turner: OK, your comments are helpful.  Here is what we're doing with our current web site:  we create .ts files by using the "text file" template and naming them .ts - and magically, the .js pane appears on the right, and when I save, it saves the .js file.  We are aware of the getter/setter problem, so I'm avoiding that - I'm not sure if there are any other gotchas for ES3/ES5.  

    We are also using AngularJS, and I have built TS interfaces that allow us to fully type all elements of the Angular $scope (variables and functions) - which is fantastic.

    So for now, I think we are making it work "as is".  The other features I mentioned would be nice but at least we can take advantage of type checking and IntelliSense.  It is SOOOOO nice to have a JS environment that warns you when you have problems, prior to runtime.  In the past, I felt that if a chicken walked across the keyboard, JS would be quite happy with it - until runtime!

    Do you foresee any problems with the environment as I described it above?

  • @Tim Ammons

    Looks like a good place to start.  We'll continue fleshing out scenarios on our end.

  • How to actually debug the source? As mention in here it sound easy, but it is not, I use google canary, and attach the process w3wp.exe, and set a breakpoint, but VS never step into typescript? How actually the debug work?

Page 2 of 3 (37 items) 123