I recently encountered a .NET Framework “Web Site” (Kentico 12 site) that hadn’t been moved into Git or subject to CI/CD best practices. Bringing that forward to 2024 certainly jogged my memory.
There was no “dev” database, so that was top priority – we never want to be working directly in production, so having a local copy was important. But the production database was 58GB – not something we wanted to be moving down to our machines. The new first step was to empty Kentico’s Recycle Bin – if you’ve got a site that is regularly replacing downloadable files (PDFs, in this case), you really want to be dumping the version history / recycle bin more often than every-five-years. That shrunk things down from 58GB 
1GB (really!) so I was pleased.
Like a lot of WebForms projects, this had a web.config with production SQL credentials. If we want it in source control, we can’t have that. It would be way better to have dev credentials in the web.config, but you know what’s even better? Having no credentials at all. I tried Integrated Authentication, and that worked. One less thing to worry about.
I don’t want to give you the impression that this had never been in source control – it was in TFS. TFS has its own “ignore” convention, so I took a look at what was in there and merge it with what Azure DevOps gives you for a standard .gitignore. That wasn’t too much. There were additional TFS bindings in the project files, but once you open the solution once in Visual Studio from Git it asks if you want to pop those off. Easy.
After building and rebuilding the supporting projects, I eventually got the system into shape where the site would load and I could click around, except it was clear the CSS was wrong. I double-checked, and the site was looking for a lot of “.min.css” files, and all I had were pre-minimized CSS files. While this project had deployed from developer desktops in the past, apparently that had involved an undocumented minimization step. Fortunately, there are not a ton of ways that this was done five years ago – and if you know someone was using Visual Studio, you can nearly guarantee that they were using Web Compiler, a very very popular way of handling this back then.
The next challenge was sorting through the build dependencies. I’d resorted to frantic Build/Clean cycles, which I’m still surprised worked. But it needed to work independently of my machine, of course, and putting an order to these things helps a lot. I had a project that was configured to compile for AMDx64 (?), and that was easy to fix.
One interesting wrinkle was managing the NuGet projects for the uncompiled Web Site. Visual Studio totally offers to manage NuGet for this type of project, but with no .csproj file, it’s clearly not tracked / managed there. (I was also on a new client laptop that didn’t have NuGet enabled, so this was maybe more hard than it had to be.) As silly as it seems, putting the DLLs directly into the Bin folder, and putting that into source control (I know! I know!) solved dependencies that weren’t resolving on the build server. It’s gross but the build at least got started.
So we’re ready for a compile – and I came into an actual compile error. A header file was calling a method I could find nowhere else in the project. How did this happen? In Web Sites, it’s actually sort of common. WebForms Web Sites didn’t actually have to be compiled before deployment – things will compile as they’re needed, and if you never run into the code block that calls the function that doesn’t exist, well…? You never error out. But if you try to compile the whole thing then you can’t do that. With some evidence that the current site (in production) was not crashing out every time the header template loaded, I came to the conclusion that this template isn’t even used, and deleted it.
One last thing: it was clear from the failing builds that more than a few files were missing. I originally thought this was related to the issue immediately above – references to stuff that no longer exists, so wipe it out – but a careful look revealed the shocking truth. A number of templates had been placed in a folder called /Debug, which is absolutely something that the default .gitignore file will ignore. Adding those weirdly named folders into a new actually-don’t-ignore section of the .gitignore file fixed it.
Now we have a green build – and all I have to do now is reinstate that CSS minimizer on the build server, update everything past unsupported .NET versions, and eventually rebuild the whole thing in MVC / dotnet core. Wish me luck!