3

While uploading my current project to our staging server I noticed that the Web.config file of my Asp.net MVC framework contains some references to assemblies called

  • Hostadapters.AspNetAdapter
  • QualityTools.Common
  • QualityTools.ExecutionCommon
  • QualityTools.Resource

I have not added the entries myself, but guessing from their names, I suspect these have been added by the "Add Unit Tests" Wizard.

The problem is, with these assemblies being referenced, the project does not run on my staging server, because it can't find the relevant DLLs. Their paths are hard-coded into the Web.config:

<httpModules>
  <add name="HostAdapter" type="Microsoft.VisualStudio.TestTools.HostAdapter.Web.HttpModule, Microsoft.VisualStudio.QualityTools.HostAdapters.ASPNETAdapter, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</httpModules>

  <dependentAssembly>
    <assemblyIdentity name="Microsoft.VisualStudio.QualityTools.HostAdapters.ASPNETAdapter" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <codeBase version="10.0.0.0" href="file:///C:/Program%20Files%20(x86)/Microsoft%20Visual%20Studio%2010.0/Common7/IDE/PrivateAssemblies/Microsoft.VisualStudio.QualityTools.HostAdapters.ASPNETAdapter.DLL" />
  </dependentAssembly>

Am I correct in thinking that these assemblies are Unit-Testing-Related?

When I tried to remove some of these entries, the server responded with an error 403 "Access Denied: Forbidden." What might be the meaning of this, and how can I avoid it?

I could simply upload the referenced DLL files somewhere onto the server, but that seems counter-intuitive. Do I have other options?

Edit: I have read the suggestion to split configuration into separate parts. It is a good suggestion, but it doesn't help me with my immediate problem of how the heck do I get any configuration working on the server?

winsmith
  • 20,791
  • 9
  • 39
  • 49

2 Answers2

3

Pain that the testing mauls your config and breaks your deployment, happened to me, too. Proper way to solve it is to use different config files for Debug, Staging and Release.

This explains what they do and points to more information.

What are the Web.Debug.config and Web.Release.Config files for?

Here are the transforms for removing the offending modules:

  <system.web>
    <httpModules>
      <add name="HostAdapter" xdt:Locator="Match(name)" xdt:Transform="Remove" />
    </httpModules>           
  </system.web>

  <system.webServer>
    <modules>
      <add name="HostAdapter" xdt:Locator="Match(name)" xdt:Transform="Remove"/>
    </modules>
  </system.webServer>
Community
  • 1
  • 1
Luke Puplett
  • 42,091
  • 47
  • 181
  • 266
  • My only remaining question is what people do on the build server, where typically, the build is release. Install VS? Copy these DLLs over? – Luke Puplett Feb 14 '12 at 12:10
0

I would have separate web.config files for staging and live regardless.

There are frequently many settings which need changing for development purposes, e.g. Cache lengths, security settings, urls etc.

From my experience, using the same config is a recipe for disaster - it takes 1 developer to change the settings to get something working locally, and then check the updated file in, and you end up with a broken staging server (or possibly live)!

If you use a build then it is simple to substitute web.config with web.live.config or web.staging.config during the build process.

Your problem then goes away.

BonyT
  • 10,750
  • 5
  • 31
  • 52
  • While that is indeed good advice, it doesn't help me fix my problem, namely: What does this entry do, and how can I remove it without breaking my installation? Also, if I should need to include the referenced DLLs, what is a good way of doing so? – winsmith Jun 15 '11 at 10:53