Swashbuckle.webapi: Error on startup

[proludio]

I am hosting an api through iis

When trying to view the docs, or really just trying to use the API, I get the following error.

[NotSupportedException: Adding or removing items from a 'HttpRouteCollection' is not supported. Please use a key when adding and removing items.]
System.Web.Http.HttpRouteCollection.System.Collections.Generic.ICollection.Add(IHttpRoute route) +121
System.Web.Http.HttpRouteCollectionExtensions.MapHttpRoute(HttpRouteCollection routes, String name, String routeTemplate, Object defaults, Object constraints, HttpMessageHandler handler) +97
Swashbuckle.Bootstrapper.Init(HttpConfiguration config) +62

Commenting out the init code, makes things run, but of course doesn't give an documents.

[slopes]

Same for me. On a basic WebAPI 5.2 project, I get the same error. Here are my dependencies:
package id="Microsoft.AspNet.WebApi" version="5.0.0" targetFramework="net45"
package id="Microsoft.AspNet.WebApi.Client" version="5.2.2" targetFramework="net45"
package id="Microsoft.AspNet.WebApi.Core" version="5.2.2" targetFramework="net45"
package id="Microsoft.AspNet.WebApi.WebHost" version="5.2.2" targetFramework="net45"
package id="Microsoft.Web.Infrastructure" version="1.0.0.0" targetFramework="net45"
package id="Newtonsoft.Json" version="6.0.6" targetFramework="net45"
package id="Swashbuckle" version="4.1.0" targetFramework="net45"
package id="Swashbuckle.Core" version="4.1.0" targetFramework="net45"
package id="WebActivatorEx" version="2.0.5" targetFramework="net45"
:+1:

[MikePennington]

Same here. WebAPI 5.2.2. IIS hosted. I'm not doing any additional swagger configuration. This error occurs immediately after installing Swashbuckle. I get the same error using both 4.1.0 and 4.0.0.

[slopes]

I fix it by setting assembly bindings in web.config
assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
dependentAssembly>
assemblyIdentity name="System.Net.Http.Formatting" publicKeyToken="31bf3856ad364e35" culture="neutral" />
bindingRedirect oldVersion="0.0.0.0-5.2.2.0" newVersion="5.2.2.0" />
/dependentAssembly>
dependentAssembly>
assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
/dependentAssembly>
dependentAssembly>
assemblyIdentity name="System.Web.Http" publicKeyToken="31bf3856ad364e35" culture="neutral" />
bindingRedirect oldVersion="0.0.0.0-5.2.2.0" newVersion="5.2.2.0" />
/dependentAssembly>
/assemblyBinding>

[domaindrivendev]

@proludio, @MikePennington - did the binding redirects solve this for you?

Swashbuckle supports WepApi 4.x and upwards. In order to do this, it is built with the WebApi 4.x bits. If you're using WebApi 5.x, this introduces a dependency conflict because your project is indirectly referencing two different strong versions of the same assemblies (the WebApi 4.x bits via Swashbuckle and the 5.x bits via your installation of WebApi).

This issue is resolved by adding the assembly binding redirects in your web/app.config as shown above. See here for a great description of this issue in general - http://blog.davidebbo.com/2011/01/nuget-versioning-part-3-unification-via.html

Admittedly, this is a little inconvenient for Swashbuckle consumers on WebApi 5.x. However, Visual Studio 2013 now introduces support to add the bindings automatically when you build your projects - https://msdn.microsoft.com/en-us/library/2fc472t2%28v=vs.110%29.aspx. I believe Nuget may also have support for this in more recent versions too.

[Ozimundi]

Sorry - I see this is closed but I still get this error (Adding or removing items from a 'HttpRouteCollection' is not supported.) using the 4.x or 5.x version of SB. I upgraded a pre-existing WCF web-service app to Web API 2 (5.2.2) and I do have the bindingRedirects that are recommended above - Nuget adds them automatically. I've used SB a ton on other Web API 2 projects recently with no issues - this is the first snag I've ever hit. Can anyone from the dev team help with this?

[domaindrivendev]

OK thx for the update ...

Bootstrapper.Init is just wiring up two per-route message handlers as described here - http://www.asp.net/web-api/overview/advanced/http-message-handlers. See the section near the bottom on Per-Route Message Handlers. From the exception you've provided it looks like this is where the exception is being raised.

Could you try uninstalling SB and wiring up your own test handler in the same way - theoretically this should repro your issue:

config.Routes.MapHttpRoute(
    "test route",
    "test_path",
    null,
    null,
    new TestMessageHandler());

Just looking at the blog I referenced above, I see he uses named parameters when calling this method. Is it possible that the order of params in your WebApi version has changed and hence is breaking this call??? Try the above and if that fails try it again with the named params:

config.Routes.MapHttpRoute(
    name: "test route",
    routeTemplate: "test_path",
    defaults: null,
    constraints: null,
    handler: new TestMessageHandler());

Let me know how this goes?

[Ozimundi]

I tried both forms of the code above in my WebApiConfig.cs file and the test path worked ok and no issures calling the wrong framework version as happens above. My TestMessageHandler is called and fails as expected with a not-implemented exception. It seems like something in Bootstrapper.Init is causing the "Adding or removing items from a 'HttpRouteCollection' is not supported." error.

[s3ncha]

I have exactly the same issue using latest Swashbuckle & WebAPI Nuget packages.
Solution is hosted under IIS and I'm getting the same error in the initialization as topic starter:

[NotSupportedException: Adding or removing items from a 'HttpRouteCollection' is not supported. Please use a key when adding and removing items.]

Any help will be greatly appreciated

[domaindrivendev]

This really is a strange one and right now I can't even repro it. I get the sense there is some sort of compatibility issue between dependencies. Looking at the stack trace posted above ....

System.Web.Http.HttpRouteCollection.System.Collections.Generic.ICollection.Add(IHttpRoute route) +121
System.Web.Http.HttpRouteCollectionExtensions.MapHttpRoute(HttpRouteCollection routes, String name, String routeTemplate, Object defaults, Object constraints, HttpMessageHandler handler) +97
Swashbuckle.Bootstrapper.Init(HttpConfiguration config) +62

The Bootstrapper makes a call to the MapHttpRoute extension method which is exactly what I expect. However, if you look at the latest source code (http://aspnetwebstack.codeplex.com) for MapHttpRoute with the signature above, it should then be delegating to Add(name, route) instead of Add(route) as it appears above.

public static IHttpRoute MapHttpRoute(this HttpRouteCollection routes, string name, string routeTemplate, object defaults, object constraints, HttpMessageHandler handler)
{
    if (routes == null)
    {
        throw Error.ArgumentNull("routes");
    }

    HttpRouteValueDictionary defaultsDictionary = new HttpRouteValueDictionary(defaults);
    HttpRouteValueDictionary constraintsDictionary = new HttpRouteValueDictionary(constraints);
    IHttpRoute route = routes.CreateRoute(routeTemplate, defaultsDictionary, constraintsDictionary, dataTokens: null, handler: handler);
    routes.Add(name, route);
    return route;
}

So certainly the stack trace above doesn't tie in with the latest WebApi 2.2 source code

[domaindrivendev]

Just released Swashbuckle 5.0.0!

I don't think it will make any difference but would you mind just pulling it down and checking?

Thanks

[Ozimundi]

Just got back to this and still no luck with SB 5.0.1. I'm going to try the .net nuget from wordnik and see if that works. Thanks for helping!

[Fabsky]

I just created a Web API project (VS 2012, .NET 4.5) and have the same problem.
Anybody found a work around ?

[Fabsky]

I've tested / debug a bit.
The exception is indeed triggered by the httpConfig.Routes.MapHttpRoute method, in the HttpConfigurationExtensions. So i can't really debug further.
I've tried to slighty change how the register method is called to follow how we register other components: In swaggerConfig.cs I've set that it receive an HttpConfiguration in the Register parameter

``` c#
public class SwaggerConfig
{
public static void Register(HttpConfiguration config)
{
... (same content as the default generated file)
}
}

Then I call register like this:

``` c#
GlobalConfiguration.Configure(config => SwaggerConfig.Register(config));

I did like this because I already register the Web API using this way. I'm loading a Web API dll in a WCF application, and it works fine.
In this case I've another error which is as strange as the previous one:

InnerException: System.Reflection.TargetParameterCountException
Message: Parameter count mismatch.
StackTrace: at System.Reflection.RuntimeMethodInfo.InvokeArgumentsCheck(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at WebActivatorEx.BaseActivationMethodAttribute.InvokeMethod()
at WebActivatorEx.ActivationManager.RunActivationMethodsT
at WebActivatorEx.ActivationManager.Run()'.

This exception happen so early that's not possible to put a breakpoint anywhere, even if I put it in code in the App_Start.

Both exception make IIS crash completely and stop the application pool, so right now I removed swashbuckle package from the project otherwise I'm blocked completely.
I hope someone will find the solution because swashbuckle seems to be impressive, but doesn't work right now.

[domaindrivendev]

Hey there, I appreciate the time you're taking to get to the bottom of this "unexplained" issue.

It's proving very difficult to resolve because a) I'm unable to repro it and b) the code in HttpConfigurationExtensions really isn't very out of the ordinary (see "Per-route Message Handlers" here http://www.asp.net/web-api/overview/advanced/http-message-handlers).

With that said, if you get the chance, maybe you could create a sample project from scratch that demonstrates the issue, zip it up and send it on so I can try get a repro?

[Fabsky]

I'm still on the issue.
I've tried to directly debug the System.Web.Http using Debug Symbols Server but I didn't succeed (it doesn't found the code source). I've then downloaded the source code from https://aspnetwebstack.codeplex.com but can't compile without snk. Using my own snk then break my code because the public token is not the expected one. It seems too much changes is needed to make it works...
It seems the source code is there: https://aspnetwebstack.codeplex.com/SourceControl/latest#src/System.Web.Http/HttpRouteCollection.cs
But I didn't notice anything reading the code.

Do you have idea on how to debug this case ?

[domaindrivendev]

SB uses WebActivatorEx to automatically hook into the startup process and I think this could be causing the problem. This allows the SB package to be pulled down and just work without making any changes to your project. However, it seems this does cause issues under certain conditions and you'll have to resort to the manual registration code, which is really just a one-liner anyway :)

This is exactly what you're doing above with the following line:

GlobalConfiguration.Configure(config => SwaggerConfig.Register(config));

But you just haven't removed the automatic hook via WebActivatorEx so the Register method is now been called with the wrong params: Try removing the following line in SwaggerConfig.cs:

[assembly: PreApplicationStartMethod(typeof(SwaggerConfig), "Register")]

Let me know if this works?

[Fabsky]

Yes I just saw this PreApplicationStartMethod attribute after my previous post. I removed it but it still crash on the routes.Add...
I just tried to move the Configure call before/after the webAPI configure to see if it changes something, but no way. I'll try to set up a new WebAPI project to see if I've the same problem

[Fabsky]

A new fresh web api project works perfectly...

My failing project is something a bit "hybrid" and I think it's the source of the problems.
I've a WCF project upgraded from .NET 4 to .NET 4.5. In this project I load the WebAPI dll so that /api/ refers to the web api project. But I've compared reference and didn't notice any difference in version...

[Ozimundi]

Fabsky - same here - my project is also a pre-existing wcf based webservice. I've scoured the web.config and checked that the servicemodel binaries are no longer referenced but this is still an issue for me as well. I use SB all the time for new web api based projects with no issues.

[rynowak]

Hi all, I'm from the WebAPI team, trying to help get to the bottom of this.

@Fabsky or anyone else hitting this issue, can you please upload a small repro project a zip somewhere (include the binaries/packages)?

A few thoughts on this (I am also unable to repro this) that should help get to the bottom of it.

-This is almost certainly a dependency/versioning issue.
-The binding redirects are necessary.
-Binding redirects don't cause an error if they fail.

We want to make absolutely certain that WebAPI 5.2.X is what's getting loaded - the best way to do that is to open the modules window (Debug->Windows->Modules) while VS while attached in the debugger.

You want to see something like this:

Note that these are the _file versions_ not the assembly versions - but you want to see that 5. and you definitely do not want to see them loaded from the GAC. If the path for System.Web.Http or System.Web.Http.WebHost starts with a c:\windows\Microsoft.Net\assembly then it's coming from the GAC and that's the problem we need to solve.

Another way to test out what version you're getting is to insert some code that would only work on a 5.X build. Add System.Web.Http.ExceptionHandling.IExceptionHandler foo = null; to your SwaggerConfig or other startup code. If this fails to compile, then you're not pulling in a 5.X build.

If you're trying to debug into WebAPI sources, follow the instructions here: http://aspnetwebstack.codeplex.com/wikipage?title=Use%20Nightly%20Builds

So, if you're not getting 5.X even though you installed 5.2.2 via NuGet, what is happening? Well, the problem is that HintPath in a project is a best-effort mechanism. If you get the HintPath wrong, there's no warning, the build system will use any available assembly. In the case of WebAPI, 4.0 was in the GAC, so a bad HintPath can fall back to that. HintPaths can be broken if you move a project relative to its dependencies, or if VS just fails to update for some reason when you add a package.

If this is the problem you can fix it by avoiding HintPath altogether.

Turn this:

    <Reference Include="System.Web.Http, Version=5.2.3.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\packages\Microsoft.AspNet.WebApi.Core.5.2.3\lib\net45\System.Web.Http.dll</HintPath>
    </Reference>
    <Reference Include="System.Web.Http.WebHost, Version=5.2.3.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\packages\Microsoft.AspNet.WebApi.WebHost.5.2.3\lib\net45\System.Web.Http.WebHost.dll</HintPath>
    </Reference>

Into this:

    <Reference Include="..\packages\Microsoft.AspNet.WebApi.Core.5.2.3\lib\net45\System.Web.Http.dll" />
    <Reference Include="..\packages\Microsoft.AspNet.WebApi.WebHost.5.2.3\lib\net45\System.Web.Http.WebHost.dll"/>

[Fabsky]

@rynowak Thank you for your post I learned some tips

And you were right, it was indeed a versionning problem
When I'm blocked like this, I revert all changes, wait 1 or 2 days to clear my mind, and start from scratch.
So I tried (again) the 1st solution put in this topic and now it worked:

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Net.Http.Formatting" publicKeyToken="31bf3856ad364e35" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-5.2.3.0" newVersion="5.2.3.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Http" publicKeyToken="31bf3856ad364e35" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-5.2.3.0" newVersion="5.2.3.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>

So I don't know what I did wrong the 1st time, but here is the notes:

• This has to be set in the web.config from the WCF project, and not the Web API project as this one doesn't use it's web.config (as the dll is loaded in the WCF project). In fact I should delete this one so that no confusion can be made in the future.
• The version to set is 5.2.3.0 (and not 5.2.2.0), I suppose a new version have been released since the post above.

I don't know if it is needed (because I didn't revert these changes) but I made these changes in SwaggerConfig.cs :

• I removed this line at the top:

``` c#
[assembly: PreApplicationStartMethod(typeof(SwaggerConfig), "Register")]

Usually I don't like "black box" so I prefer to specifically put a line to load a component, and not let the system do it for me. Of course this is completely subjective.
- I changed the Register method to add the HttpConfiguration in parameter, and use this parameter instead of the global one

``` c#

        public static void Register(HttpConfiguration config)
        {
            var thisAssembly = typeof(SwaggerConfig).Assembly;

            config
                .EnableSwagger(c =>

• I call the register using the Configure method:

c# GlobalConfiguration.Configure(config => SwaggerConfig.Register(config));

[rynowak]

This has to be set in the web.config from the WCF project, and not the Web API project as this one doesn't use it's web.config (as the dll is loaded in the WCF project). In fact I should delete this one so that no confusion can be made in the future.

Yup, this is an easy thing to forget. Binding redirects only have to an effect in the entry point project.

Glad to hear that you solved this issue. Anyone else still having trouble? Have a repro project you want me to look at?

[Ozimundi]

Thanks again for keeping up with this! Still no joy here :( I went through the steps you outline above - I added the reference to IExceptionHandler and it compiles fine. Looking at the modules I don't see either of the modules you list loading - perhaps a side effect of it failing. The solution only has one host project so there is only a single web.config and it has always contained the proper binding redirects. This is a large project so it's tough to create a repro version. Any other thoughts or alternatives?

[rynowak]

Sorry @Ozimundi I was out for a few days. Possible to post the relevant web.config and .csproj parts here?

If you temporarily take out swashbuckle does the app load and work correctly? Can you try that and then look at the modules window?

Can you confirm that the web.config is in the project root.

[Ozimundi]

Yes, without the call to init SB all works fine - add it back and the whole web stack breaks. I loaded it and in the modules window both dll's show up with the same version as your example above. The web config is in a host project and is in the root.

Here's web.config:

<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
  <configSections>
    <section name="loggingConfiguration" type="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.LoggingSettings, Microsoft.Practices.EnterpriseLibrary.Logging, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
    <section name="cachingConfiguration" type="Microsoft.Practices.EnterpriseLibrary.Caching.Configuration.CacheManagerSettings, Microsoft.Practices.EnterpriseLibrary.Caching, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
  </configSections>
  <appSettings configSource="appSettings.config" />
  <cachingConfiguration defaultCacheManager="DefaultCacheManager">
    <cacheManagers>
      <add name="DefaultCacheManager" expirationPollFrequencyInSeconds="60" maximumElementsInCacheBeforeScavenging="1000" numberToRemoveWhenScavenging="10" backingStoreName="Null Storage" />
    </cacheManagers>
    <backingStores>
      <add encryptionProviderName="" type="Microsoft.Practices.EnterpriseLibrary.Caching.BackingStoreImplementations.NullBackingStore, Microsoft.Practices.EnterpriseLibrary.Caching, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" name="Null Storage" />
    </backingStores>
  </cachingConfiguration>
  <!--
    For a description of web.config changes see http://go.microsoft.com/fwlink/?LinkId=235367.

    The following attributes can be set on the <httpRuntime> tag.
      <system.Web>
        <httpRuntime targetFramework="4.5" />
      </system.Web>
  -->
  <system.web>
    <httpRuntime maxQueryStringLength="20480" />
    <compilation debug="true" targetFramework="4.5.1"></compilation>
    <caching>
      <outputCacheSettings configSource="outputcache.config" />
    </caching>
    <pages controlRenderingCompatibilityVersion="4.0" />
  </system.web>
  <runtime xmlns="">
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="WindowsBase" publicKeyToken="31bf3856ad364e35" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="NLog" publicKeyToken="5120e14c03d0593c" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-3.2.0.0" newVersion="3.2.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Http" publicKeyToken="31bf3856ad364e35" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-5.2.3.0" newVersion="5.2.3.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Net.Http.Formatting" publicKeyToken="31bf3856ad364e35" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-5.2.3.0" newVersion="5.2.3.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Enyim.Caching" publicKeyToken="cec98615db04012e" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-2.13.0.0" newVersion="2.13.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Http.WebHost" publicKeyToken="31bf3856ad364e35" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-5.2.3.0" newVersion="5.2.3.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
  <system.webServer xmlns="">
    <security>
      <requestFiltering>
        <requestLimits maxUrl="30720" maxQueryString="20480" />
      </requestFiltering>
    </security>
    <modules runAllManagedModulesForAllRequests="true">
      <!--<add name="UrlRoutingModule" type="System.Web.Routing.UrlRoutingModule, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />-->
    </modules>
    <handlers>
      <!--<add name="SwashbuckleUiHandler" verb="*" path="swagger/ui/*" type="Swashbuckle.Application.SwaggerUiHandler, Swashbuckle.Core" preCondition="managedHandler" />-->
      <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
      <remove name="OPTIONSVerbHandler" />
      <remove name="TRACEVerbHandler" />
      <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
    </handlers>
  </system.webServer>
</configuration>

And here's the csproj - not sure which is relevant - let me know if you want to see more:

  <ItemGroup>
    <Reference Include="Common.Logging, Version=3.0.0.0, Culture=neutral, PublicKeyToken=af08829b84f0328e, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\packages\Common.Logging.3.0.0\lib\net40\Common.Logging.dll</HintPath>
    </Reference>
    <Reference Include="Common.Logging.Core">
      <HintPath>..\packages\Common.Logging.Core.3.0.0\lib\net40\Common.Logging.Core.dll</HintPath>
    </Reference>
    <Reference Include="Acme.DocUtil, Version=14.3.5577.1262, Culture=neutral, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\packages\Acme.DocUtil.1.0.9\lib\Acme.DocUtil.dll</HintPath>
    </Reference>
    <Reference Include="Acme.Framework.Configuration, Version=2.0.5406.24926, Culture=neutral, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\packages\Acme.DocUtil.1.0.9\lib\Acme.Framework.Configuration.dll</HintPath>
    </Reference>
    <Reference Include="Acme.Framework.Globalization, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\packages\Acme.Framework.Globalization.1.1\lib\Acme.Framework.Globalization.dll</HintPath>
    </Reference>
    <Reference Include="Acme.Framework.Logging">
      <HintPath>..\packages\Acme.Framework.Logging.1.0.3\lib\Acme.Framework.Logging.dll</HintPath>
      <Private>True</Private>
    </Reference>
    <Reference Include="Acme.Logging, Version=1.73.0.0, Culture=neutral, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\packages\Acme.Logging.1.73\lib\Acme.Logging.dll</HintPath>
    </Reference>
    <Reference Include="Microsoft.CSharp" />
    <Reference Include="Newtonsoft.Json, Version=6.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\packages\Newtonsoft.Json.6.0.8\lib\net45\Newtonsoft.Json.dll</HintPath>
    </Reference>
    <Reference Include="NLog, Version=3.2.0.0, Culture=neutral, PublicKeyToken=5120e14c03d0593c, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\packages\NLog.3.2.0.0\lib\net45\NLog.dll</HintPath>
    </Reference>
    <Reference Include="System.Data.DataSetExtensions" />
    <Reference Include="System.Net" />
    <Reference Include="System.Net.Http" />
    <Reference Include="System.Net.Http.Formatting, Version=5.2.3.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\packages\Microsoft.AspNet.WebApi.Client.5.2.3\lib\net45\System.Net.Http.Formatting.dll</HintPath>
    </Reference>
    <Reference Include="System.Web.DynamicData" />
    <Reference Include="System.Web.Entity" />
    <Reference Include="System" />
    <Reference Include="System.Configuration" />
    <Reference Include="System.Data" />
    <Reference Include="System.Drawing" />
    <Reference Include="System.EnterpriseServices" />
    <Reference Include="System.Runtime.Serialization" />
    <Reference Include="System.Web" />
    <Reference Include="System.Web.Http, Version=5.2.3.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\packages\Microsoft.AspNet.WebApi.Core.5.2.3\lib\net45\System.Web.Http.dll</HintPath>
    </Reference>
    <Reference Include="System.Web.Http.WebHost, Version=5.2.3.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\packages\Microsoft.AspNet.WebApi.WebHost.5.2.3\lib\net45\System.Web.Http.WebHost.dll</HintPath>
    </Reference>
    <Reference Include="System.Xml" />
    <Reference Include="System.Xml.Linq" />
  </ItemGroup>

Thanks for taking time to help with this!

[rynowak]

Looking at your references and redirects everything seems right. Only things I can think of:
1). Install swashbuckle and comment out the bootstrapping code - look at the diff of your project file and redirects
2). Try adding some code that depends on swashbuckle, but doesn't call into it's startup code (like what I mentioned with IExceptionLogger).
3). Do a _manual clean_ (close VS and fully delete your project's output folder - doing a rebuild in VS is much more conservative than this.
4). If you're running this in IIS Express, find where the site is on your local system and make sure to wipe out all the files (in case something is failing in deployment)

[kpfaulkner]

Same problem.... have tried whats suggested... but still no luck :(

[fokkoru]

The same problem, any updates?

[sharadagarwal]

@kpfaulkner @fokkoru : Check which file your binding redirects are in. Use web.config if you are deploying locally to the Azure Emulator using IISExpress, or .dll.config if you are deploying to Azure in the cloud. I had mine in the wrong file and this problem went away after fixing that.

[robhoffmann32]

I am having this same problem with an MVC/Web Forms/Web API hybrid project. Any solution?

[robhoffmann32]

I was able to fix the issue by checking out the repo, upgrading the following:
Target framework to v4.5
System.Net.Http to version 2.2.29.0
System.Net.Http.Formatting to Version=5.2.3.0
System.Net.Http.Primitives to Version=4.2.29.0
System.Web.Http to Version=5.2.3.0
Then I built the solution and used the new DLL out of the bin in my solution.

[dbarbee]

I had the same problem in a Web API project I was writing. To eliminate my incompetence, in VS2015, tried a new WebApi project Solution->add->New Project. In the wizard ASP>NET Web Application. From ASP>NET 4.5.2 Templates choose Web API (left the MVC and Web API boxes checked as per default), Change Authentication to "No Authentication" clicked on "OK." From the nugget package manager for the new project, added Swashbuckle v5.3..2 (latest stable). Verified "SwaggerConfig.cs" was added to "App_Start". Run in debugger, get the error everyone's been seeing:

Server Error in '/' Application.

Method not found: 'Swashbuckle.Application.SwaggerEnabledConfiguration Swashbuckle.Application.HttpConfigurationExtensions.EnableSwagger(System.Web.Http.HttpConfiguration, System.Action`1)'.

Added the following at the end of the "assemblyBinding" section of "web.config":

  <dependentAssembly>
    <assemblyIdentity name="System.Web.Http" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-5.2.3.0" newVersion="5.2.3.0" />
  </dependentAssembly>

Rebuilt the project, and it runs and shows the default page.

When I go to "swagger/ui/index" I get the following error:

500 : {"Message":"An error has occurred.","ExceptionMessage":"Method not found: 'System.Net.Http.Formatting.MediaTypeFormatterCollection System.Web.Http.HttpConfiguration.get_Formatters()'.","ExceptionType":"System.MissingMethodException","StackTrace":" at Swashbuckle.Application.HttpConfigurationExtensions.SerializerSettingsOrDefault(HttpConfiguration httpConfig)\r\n at Swashbuckle.Application.SwaggerDocsConfig.GetSwaggerProvider(HttpRequestMessage swaggerRequest)\r\n at Swashbuckle.Application.SwaggerDocsHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)\r\n at System.Net.Http.HttpMessageInvoker.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)\r\n at System.Web.Http.Dispatcher.HttpRoutingDispatcher.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)\r\n at System.Net.Http.DelegatingHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)\r\n at System.Web.Http.HttpServer.<>n__FabricatedMethod9(HttpRequestMessage , CancellationToken )\r\n at System.Web.Http.HttpServer.d__0.MoveNext()"} http://localhost:27922/swagger/docs/v1

Adding:

   <dependentAssembly>
    <assemblyIdentity name="System.Net.Http.Formatting" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-5.2.3.0" newVersion="5.2.3.0" />
  </dependentAssembly>

to the "assemblyBinding" section and rebuilding the project fixes that error and I can see the Swagger UI

Seems like adding the Swashbuckle package should make sure those "dependentAssembly" entries are included in Web.Config if possible.

Going back to the original project, adding those entries to Web.config fixed it as well.

Thanks for the post from Fabsky on Apr 1 2015 for suggesting the fix

[heldersepu]

I've been using Swashbuckle for a while and never encountered this issue ...
Can someone post a link to a project to reproduce the issue?

[brutaldev]

I solved my issue from information in @Fabsky's answer above. I believe the parameter count problem is coming from using the following attribute: [assembly: PreApplicationStartMethod(typeof(SwaggerConfig), "Register")].

If you are using OWIN then you would normally change the Register function to take a HttpConfiguration object instead of using the default GlobalConfiguration generated code. Altering the Register method like this caused the error for me since I assume the start method call being made by applying the attribute should have zero arguments.

Affer making the changes to the Register method for OWIN, you should just call it from Startup.cs like all the other registration static classes.

SwaggerConfig.Register(config);

[Cloudmersive]

I fix it by setting assembly bindings in web.config
assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
dependentAssembly>
assemblyIdentity name="System.Net.Http.Formatting" publicKeyToken="31bf3856ad364e35" culture="neutral" />
bindingRedirect oldVersion="0.0.0.0-5.2.2.0" newVersion="5.2.2.0" />
/dependentAssembly>
dependentAssembly>
assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
/dependentAssembly>
dependentAssembly>
assemblyIdentity name="System.Web.Http" publicKeyToken="31bf3856ad364e35" culture="neutral" />
bindingRedirect oldVersion="0.0.0.0-5.2.2.0" newVersion="5.2.2.0" />
/dependentAssembly>
/assemblyBinding>

This actually worked - in particular the 4.2.0 for System.Net.Web