The ClickOnce dilemma: Code Identity versus Security - What to do?

We have quite some room for improvement in our application lifecycle management. We don't use TFS or any other suite (shame on us, I know).

Anyway, one of the aspects we currently ponder about is code identity. In other words: Auditors ask us how we ensure that the software tested and accepted by the departments is exactly and with no alternations the assembly we deploy for productive use and not some tinkered-with version. "That's easy", we say, "it isn't!". Because some configuration variables are set between approval and release, the ClickOnce hashes differ and thus does the whole thing.

That's the story so far, but we want (and have) to get better at what we do, so there's no w开发者_Go百科ay around creating our assemblies stateless and oblivious to their environment. But then we will have to set the environment at runtime, our options here are:

1. Using Application settings and excluding the application configuration from the ClickOnce hash. This sucks because we can't sign the ClickOnce Manifest that way, so users will always be prompted a "watch out, you don't know this guy" kind of message.

2. Passing Query-String parameters to the application file and using those to distinguish between test and productive environment. I don't like this because it's too open and enables any user to control the important bits (like dbhost or whatever).

Passing in something like "is_test=1" means there's a lot of inline-switching going on, and that on the other hand could mean that the assembly behaves different in production than in test, which brings us back to the start, although we've ensured Assembly-Identity on the way.

I think all that is rather unsatisfying and there must be a better way to do it. How can this be done by little means (meaning without TFS or similar monstrosities)?

I just messed around with the ApplicationDeployment class a little. I think what I have now is pretty close to what I was looking for.

    private static void GetDeploymentEnvironment()
    {
        if (ApplicationDeployment.IsNetworkDeployed)
        {
            ApplicationDeployment dep = ApplicationDeployment.CurrentDeployment;
            FileInfo f = new FileInfo(dep.UpdateLocation.AbsolutePath + ".env");
            if (f.Exists)
            {
                /// read file content and apply settings
            }
        }
    }

This enables me to put a file in the deployment folder (where the .application-file resides) that I can use to override settings. If there is no such file, well...nothing gets overridden. Whatever I do with the content of this file, the Assembly Identity is preserved.

EDIT : Just a hint, as you see this is useful only for applications deployed as Online Only. You cannot start the same ClickOnce .application file from different locations in the Available Offline scenario.