How do I convert an old ASP.NET WebForms app to an application?

Rod At Work 866 Reputation points

Back in the early 2000s Microsoft's WebForms projects were of one type. (I don't remember what they were called back then - it's been too long.) Then Microsoft upgraded the project type to what I think was called a WebForms Application. (I'm not certain, but I think that's correct.) I'm trying to migrate an old TFS project to GitHub, but want to get rid of all the .DLLs and .PDBs in it. However, although there is a .sln file, there is no .vbproj file. (This is a VB.NET project.) And there's a folder bin folder that has an old AJAXControlToolkit collection in it. Searching through the code I see that it does take advantage of the AJAXControlToolkit, but because there's no .vbproj, there's no NuGet packages. (I hope this makes sense.)

So, how to I convert this thing from whatever that original project type was, to a WebForms Application project, so I can include the ALAXControlToolkit NuGet package?

A set of technologies in the .NET Framework for building web applications and XML web services.
3,363 questions
{count} votes

Accepted answer
  1. Albert Kallal 5,146 Reputation points

    Hum, ok.

    first up, for git-hub friendly sites, including other projects (multiple projects), using nuget packages (as you noted), and many more reasons?

    Yes, a VERY good idea to convert to a "application".

    It also means you ONLY get a "bin" folder during build process, and not one, or many .dll's for each web page.

    So, that's the good part!!!

    So, I assume that you been/are/have been opening this project using:

    File->open web site.

    And as you note, you don't really have a proper project file (.sln).

    You also don't mention what version of vs you are using.

    However, the basic steps are:

    Create a brand new empty blank web site application.

    Then right click on the new base project, and choose:

    Add existing items.

    Browse to the existing folder/site you have, and select all of the folders and pages you have. (of course, you skip the .dll's and bin files).

    Now, keep in mind that EACH page requires some changes, but you find a option in the new site called this:

    (and note how this option DOES NOT exist for a web site, but ONLY for a web site application!!!!).

    User's image

    Now, what does the above do?

    Well, it will modify each and every page. So the first line "page directive" in each web page will have say this:

        <%@ Page Title="Contact" 
            Inherits="Contact" %>

    Note in above, the code behind is called CodeFile.

    However, for a web site application, that will change to this:

        <%@ Page Title="Contact" 
            Codebehind="Contact.aspx.vb" %>

    Note the Inherits change (has a name space now), and note the change to NOW using Codebehind in place of CodeFile.

    So, the convert process should change EVERY such aspx page for you.

    Now the hard part!

    The above should get you at least all the changes to the page directive made for you.

    The above ALSO should trigger creating of all "designer" files. (web site don't have those, web site application does).

    However, while the above is a basic starting point, this is QUITE a bit beyond this post and format of a simple forum post.

    So, some of the changes? Yes, they are automated for you, but the next part is where all the works REALLY starts.

    So, you want to now add the nuget packages.

    It been some time since I done the above. And I can't remember if you have to fix/remove all compile errors before the convert option works.

    And the other REALLY bad part about web sites? They put references in the bin folder, and you UNDER NO circumstances want that for a web site application.

    After all, I often delete the bin folder, or at the very least "clean project".

    In other words, where I come from, the concept of a "build project" means the bin folder(s) are re-created from scratch, not something that can have "years" of funny .dll's here, there, and everywhere. (and worse to update them!!!).

    Hence, once again, the build's process for a "application" is a 100x better process, since then IIS is not going compile your code, nor does it have to!!! (you the developer do that!!!).

    This will of course suggest that some work in regards to "references" and some .dll's used in that project will be required.

    So, the conversion process is not automated, but some parts are.

    The other tip?

    I assume you have good solid skills in working with web site "applications", so you know all of the little "ins and out" of working with such projects. The MORE experience you have working with such projects in the past, the better you be able to fix things.

    There is also a walk through here:

    About the only "down side" of a web application? Well, if you change one line of code behind? Then you have to re-deploy the whole site. However, I consider this a VERY small price to pay for all of the advantages you get.

    However, much will depend on the size and scope of this project. I also suggest creating a folder called MyAppCode, and NOT using App_code.

    So, I do find that web site "applications" tend to play rather nice with git-hub. And the vs2019 and vs2022 git-hub integration works really nice for web site applications.

    1 person found this answer helpful.

0 additional answers

Sort by: Most helpful