"Anthony Bollinger" <to*******@NEVERsendto.org> wrote in message
news:O7**************@TK2MSFTNGP03.phx.gbl...
I am learning ASP.NET 2.0 while working to modify an ASP.NET 1.0
application. Here is the first line of one of the files (default.aspx):
<%@ Page Language="vb" AutoEventWireup="false"
Codebehind="default.aspx.vb" Inherits="vwma._default"%>
All I have are the files on the server.
Ah - then you have a bit of a problem...
There is no file named default.aspx.vb
But there was once - that's where all the VB.NET code for the page in
question was stored.
nor is there a file named vwma._default. Where is the code for this page?
vwma_default is the name of a class, not necessarily the name of a class
file, though the two are often the same...
I have read that all the VB code can be compiled into a DLL, but which DLL
is this?
Almost certainly the same name as the web project, which will almost
certainly be found in the \bin folder.
Basically, you have three choices here:
1) Find (one way or another) the original source files for the web app.
Where's the original developer? Was it developed under some sort of version
management system e.g. Visual SourceSafe? Backup tapes? Etc.
2) Find a utility that will decompile the DLL file(s) into their original
source code. However, this is not guaranteed to solve all your problems, nor
will it necessarily extract all the compiled code into neatly arranged and
separated VB modules.
http://www.google.com/search?sourcei...T%22+decompile
3) Assuming the existing site is actually deployed and running somewhere,
reverse-engineer it i.e. use it as a prototype and rewrite it in ASP.NET 2.
You have my sympathies - most developers (especially contractors) who've
been around for a while have encountered something similar to this at least
once. About 5 years ago, just as the early pre-release of .NET was filtering
through, I had to reverse-engineer a middle-tier component written in CORBA,
in between an ASP front-end and SQL Server 6.5 back-end. No source code, no
documentation, no nothing! Easiest way turned out to be to examine SQL
Server trace logs ... :-)