If you’re using TypeScript, it’s good to set up your .csproj file so that it builds all the TypeScript files and compiles them to JS files. This makes sure that when someone else checks in a .TS file, you’ll get the corresponding .JS file without having to regenerate them manually, and that means you can avoid checking the .JS files into source control.

Here’s what you need to do to set up TypeScript for both developers and your build server.

1) Install the TypeScript VS2012/2013 extension from http://www.typescriptlang.org/#Download. All your developers need to do this because the changes in this post make the TS compiler run every time the project builds.

2) If your developers or your build server use VS2012, or a mix of VS2012 and VS2013, you’ll need to edit your .csproj file to include some defaults. (We currently develop in VS2013 but the build server is VS2012.) Open the .csproj file in a text editor and insert the following segment. It goes very near the top of the file — in our project, it goes on line 5, after the <Import> elements, before all the other <PropertyGroup> elements.

<PropertyGroup Condition="!Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.Default.props')">
 <!-- These are the defaults introduced in VS2013, duplicated here for VS2012 builds -->
 <TypeScriptRemoveComments>false</TypeScriptRemoveComments>
 <TypeScriptNoImplicitAny>false</TypeScriptNoImplicitAny>
 <TypeScriptNoResolve>false</TypeScriptNoResolve>
 <TypeScriptGeneratesDeclarations>false</TypeScriptGeneratesDeclarations>
 <TypeScriptModuleKind>amd</TypeScriptModuleKind>
 <TypeScriptOutFile>
 </TypeScriptOutFile>
 <TypeScriptOutDir>
 </TypeScriptOutDir>
 <TypeScriptSourceMap>true</TypeScriptSourceMap>
 <TypeScriptMapRoot>
 </TypeScriptMapRoot>
 <TypeScriptSourceRoot>
 </TypeScriptSourceRoot>
 <TypeScriptTarget>ES5</TypeScriptTarget>
 <TypeScriptAdditionalFlags>
 </TypeScriptAdditionalFlags>
 <TypeScriptEnableCompileOnSave>true</TypeScriptEnableCompileOnSave>
 </PropertyGroup>

2) Near the end, after <Import Project=”$(MSBuildBinPath)\Microsoft.CSharp.targets” />, insert this;

<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets" />

3) If you have a build server set up, you’ll need to install the TypeScript compiler on the build server. Otherwise, your build server is going to fail to generate the JS files. So head to your machine at either

For a VS2012 build server: C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\TypeScript
For a VS2013 build server: C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\TypeScript

And copy the TypeScript folder to the same location on the build server. This installs the compiler into the location mentioned in the <PropertyGroup> element from Step 2.

This should do you. Save up the .csproj and reload it in Visual Studio. When you build the project, all the .JS files should be generated automatically every time you build. You may need to exclude the .JS files from source control.

I’ve noticed a technique that’s been very helpful for me when writing software. Hopefully it’s a tool you might use, too.

When I come to an impasse — when I’m not quite sure what the next step in my work is — I find that I often hit a particular technical problem I can’t trivially solve. The problem that prompted this blog post was one that mashed together problems in Entity Framework, Generics, and Entity SQL. I realised this wasn’t going to be trivial, and I wasn’t sure how to proceed.

So, I hit stack overflow, clicked ‘Ask a question‘, and got to writing, I spent a while formulating and re-writing the question for the unknown programmers of the internet, trying to state the core of the problem and the way I wanted it solved. It included the problem, my approaches, my half-baked architectures.

Interesting alchemy starts to happen when you do this. You start to realise your problem in more detail. You start to see the flaws in your own thinking. You come to understand how you may have limited yourself, driving for the wrong kind of solution. When you get your own thoughts out on paper, you can see, then correct, the flaws.

So a question that starts;

“I’m having trouble querying for tables…

transmutes through

“Entity Framework doesn’t allow generics…

through

“I’m thinking of using code generation…

to

“If I can get hold of the EDMX model, I can run a code generator…

And you start to realise the shape of the problem you really help with.

In the end, stating the problem clearly for the folks on Stack Overflow (and this is a minimum standard for asking a question) is often all you need to see the solution to your own problem. So you may not need to post the question in the end. In this respect, it’s very similar to Rubber Duck Debugging, but with the additional benefit that, should you not figure it out, you can immediately post a high-quality, thoughtful question to Stack Overflow.

Anyway, you probably use something like this already, but it’s just a reminder that the technique is available.