CODEWITHSUNDEEP
asp.netasp-classic
RyanfaeScotland
RyanfaeScotland

Reputation: 1213

Have I unnecessarily introduced the need to compile this legacy Classic ASP project?

I was tasked with introducing some new functionality into a legacy system which would be a great cost saving to the business.

An initial investigation revealed it was a Classic ASP project written with VB. Not being overly experienced with Classic ASP I researched if I could use ASP.Net for my additions and found they work together quite nicely. I introduced some simple new functionality, completed some initial tests and confident it would work set about the remainder of the project.

During development I found that I couldn't access data set in the Application_OnStart event of the global.asa file from my .ASPX pages and as a workaround I created a Global.asax file which sets the same values on the Application_Start event. This has meant a little configuration duplication / loss of DRYness since these files contain the database details rather than reading them in from a separate config file (these in essence ARE the config files) which was deemed an acceptable trade-off for time saved separating them out.

However, in moving from our DEV to our UAT environment I'm now finding that changes in the global.asa file on the UAT server are reflected immediately whilst changes in the Global.asax file require a recompile and redeploy of the .dll to take effect. Changes to .aspx pages are reflected immediately with no need to recompile.

Is this always the case or have I inadvertently introduced this issue during the setup and development of the project? If so can you explain how so?

Upvotes: 1

Views: 108

Answers (1)

John
John

Reputation: 4663

Classic ASP and ASP.net are different technologies, but you can use them in the same website (in the same way you can use Classic ASP and PHP in the same website if you really want to). One consequence of this - as you have discovered - is that each needs its own database connection. Another which frustrates many people is that session variables created in Classic pages are invisible to .net pages and vice versa.

As you have also discovered, Classic uses code which is executed at runtime while .net uses compiled code. The need to recompile the project following changes is part and parcel of ASP.net development.

I should also mention that Classic uses VBScript. This is a similar, but not identical language to VB, or VB.net

Classic ASP is regarded as "legacy" - if you're unfamiliar with it then it makes sense to add any new functionality in a technology with which you are more familiar

Upvotes: 1

Related Questions