CODEWITHSUNDEEP
asp.net-mvcvisual-studiotypescript
Zoltán Tamási
Zoltán Tamási

Reputation: 12809

How to put TypeScript sources into separate VS project?

I have a long-running web project (3-4 years old), which is based on ASP.NET MVC 5. I have a large client-side codebase too, written in TypeScript. Due to earlier conventions, the TypeScript sources are part of the MVC 5 csproj project, so it gets compiled together with the back-end.

This structure is very unfortunate due to many reasons. A few main ones are: violation of SRP, strongly coupled to backend, no way to separately maintain and build backend, no way to separately maintain and build front-end, etc.

I'd like to separate the client-side codebase into a new Visual Studio project, however, I have no idea what the best way would be, as Visual Studio doesn't provide a way to have clean TypeScript projects (at least as far as I know).

I'm using Visual Studio 2015 with TypeScript 2.0. What options do I have?

Upvotes: 1

Views: 307

Answers (2)

stakx - no longer contributing
stakx - no longer contributing

Reputation: 84835

First, if your client-side code (the TypeScript application) does not need its own Web.config file — that is, you don't need to configure IIS authorization, redirects, etc. — you can simply use the "HTML Application with TypeScript" project type in Visual Studio.

However, if both your client and server code need their own Web.config and they get deployed to the same IIS web site, having two separate ASP.NET projects becomes more difficult, because one needs to merge two Web.config files… which is impossible, AFAIK.

I was facing a similar problem, but in my case I had a AngularJS-based web application programmed in TypeScript, and an ASP.NET Web API backend.

The best I could think of so far that doesn't require any additional build steps was to not move the TypeScript code into a separate project, but to move the Web API / MVC code instead. The client-side TypeScript ends up in the ASP.NET web project, the Web API goes into a class library.

Two remaining pain points are the shared Web.config and bootstrapping Web API via Global.asax, which ends up in the "wrong" project. Regarding the Web.config, it might be possible to further extract Web API configuration into a separate .config file via the configSource mechanism. I don't see a way to get the Web API bootstrapping in Global.asax out of the (otherwise client-only code) ASP.NET project.

Upvotes: 1

Sean
Sean

Reputation: 3052

IMO, client side code like your javascript or css should be together with your "backend" code, the backend code doesn't mean to be your entire backend code, it should be a thin controller layer application which only handle http request and server side rendering

you could separate your monolithic application into multiple service layer and one frontend layer which only handle httprequest and rendering

the problem to separate only javascript and css into a single project is

  1. it makes deployment complex, when you have incompatibility between your client code and server code, you don't know which should be deploy first

  2. you can't do js hash (you don't need to deal with client cache) when you separate your client code from backend

Upvotes: 0

Related Questions