C# dll issue?



  • Having an issue where an Asp.NET page is displaying the wrong value on the web page. Tested with a variety of browsers and incognito mode on chrome, so I'm reasonably sure it's not webpage caching causing the issue.

    Scenario:

    I have the main web project referencing a global library settings library. This global library settings project has #if DEBUG statements to reference variables either in the development project settings, or the production project settings.

    Web
    |
    v
    Global Settings Debug? Yes -> Debug Settings project
    |
    v
    Production Settings project

    I have confirmed that the global library setting does NOT contain the debug constants, ditto for both settings projects

    No matter what I do, it seems to be pulling from the development project DLL.

    Any tips on things I can check? (Solution configuration manager appears correct)


  • FoxDev

    Do you get the correct values if you build your code in Release mode?



  • Sure don't. I've said f it for now and included the debug and release projects in the main library project, split using if debugs. I'll have to revisit this later on how to keep prod configuration info from developers, but since it's just me and four config files, it can be a task for another day.



  • My suggestion... change that way you're doing this. If you continue with the "debug build uses non-production settings" idea, you will never be able to deploy a debug build to production. This can be handy when problems are difficult to reproduce.



  • Furthermore, you won't be able to run a release build against the development environment, which is useful when you suspect that your code is doing something naughty that doesn't crop up in a debug build.



  • I will never deploy a debug build to production. I will deploy a TRACE build to production if required.



  • @Matches said:

    I will never deploy a debug build to production.

    Way to paint yourself into a corner there. What about @tarunik's other point that the same strategy prevents you from running a release build against prod?

    Essentially, you can never test the same binaries you are going to deploy. Build -> Test -> Build -> Deploy is not the best way to go.



  • I will never move production to DEVELOPMENT in the way you are suggesting, but my application does allow for staging up or staging down in a fresh environment which I've built in such a way that:

    1. I can create a new windows 2012 VM (or clone from an existing VM)
    2. Run a sql script to 100% recreate the environment sql tables
    3. Run an import script to import any relevant data (in the process decrypting production / re-encrypting dev passwords if required)

    I believe in separation of environments / duties, but more specifically I'm a firm believer that if you can't reproduce your entire environment from a script, you're DOING IT WRONG and your DR plans cannot work.

    More specifically, production / debug switch statements are encryption keys and connection strings. They are to protect data. The code doesn't care if it runs in debug or production mode.



  • @Matches said:

    More specifically, production / debug switch statements are encryption keys and connection strings. They are to protect data. The code doesn't care if it runs in debug or production mode.

    I personally prefer having the runtime-environments switch be a separate, runtime switch...that way, it can be extended to handle cases like (shock, horror) multiple prod environments! Or having to stand up an extra test instance temporarily, for that matter...

    @Matches said:

    I will never move production to DEVELOPMENT in the way you are suggesting, but my application does allow for staging up or staging down in a fresh environment which I've built in such a way that:

    I was saying that you should be able to run a release build against dev, because the debug/release build dichotomy can mask certain types of issues...



  • I prefer having a clean switch so i can create a debug build, a main production build, and then if needed I can have different configurations for staging or mock environments. All it requires is adding a new configuration and adding details to the transform file which takes only a few minutes. It allows for variations in the build environment, and has a hard error flag at compilation time in the event you missed any field you need to worry about. But my configuration swaps fully support load balancer/multi server environments.


Log in to reply