Custom ConfigurationSectionHandlers in InstallerClasses
I'm writing an installer class for an MSI Setup Project, and find myself needing to manipulate my web.config containing a custom ConfigurationSection. This should be trivial seeing as my SectionHandler code is bundled with the rest of the application, but fails miserably on my GetSection() call, because the DLL containing it is unavailable to MSIEXEC, which runs from C:\Windows\System32. What to do, what to do?
Several options:
1) Rather than using the custom ConfigurationSection, I can open my web.config as a standard XmlDocument and do the changes manually.
Pro: No depenencies.
Con: More complicated, untyped, more error-prone.
2) Copy my section handler DLL to %SystemRoot%\System32 during installation.
Pro: Simple.
Con: Ugly, goes against the "Don't touch System32" philosophy that serves us well.
3) Launch a new AppDomain whose BaseDirectory points to my bin path, and do all my config-mangling there.
Pro: Clean, strongly typed, etc.
Con: More work. Causes my relatively simple installer class to grow in size and complexity.
Right now, I'm leaning towards #2. Keeping it simple, even if ugly. After all, no-one really looks in System32, and uninstalling the application will uninstall those files as well. No harm done.
Anyone got any other approaches, mitigating factors or other suggestions?
2 Comments
Comments have been disabled for this content.
Marc Glick said
Did you ever succeed at doing this? I've tried, but continue to get permission issues with my new appdomain?
paddy said
Similar to option 3 you could hook up to the AppDomain.CurrentDomain.AssemblyResolve event. When the handler is raised you can load the assembly yourself and return it to the AppDomain. ex: private Assembly CurrentDomain_AssemblyResolve( object sender, ResolveEventArgs args) { return Assembly.LoadFile("assemblyLocation"); } You can find the assembly location by looking for the Context.Parameters["assemblypath"] value or Assembly.GetExecutingAssebly().Location property. The fully qualified name of the assembly that the AppDomain can't resolve is args.Name.