Unable to Unit Test Routes using v2.1

[RobARichardson]

When I try to initialize my routes from inside a Test Fixture within another class library, I'm seeing the following types of issues.

FIRST: If I attempt something like...

routes.MapAttributeRoutes(config => { config.AddRoutesFromController(typeof(MyController)); });

...I'll get an empty route collection. If I use the Generic form of this method, I'll get the following error even though MyController definitely inherits from System.Web.Mvc.Controller:

System.Security.VerificationException : Method AttributeRouting.Web.Mvc.AttributeRoutingConfiguration.AddRoutesFromController: type argument 'Namespace.Subnamespace.MySettingsController' violates the constraint of type parameter 'T'.

SECOND: When I attempt something like....

routes.MapAttributeRoutes(config => { config.ScanAssembly(typeof(MyController).Assembly); });

...I'll again get a completely empty route collection.

*NOTE: This is my first version of AttributeRouting for which I'm writing routing unit tests so I have no idea if previous versions do or do not have this issue.

[mccalltd]

First, and most regrettably, v2 introduced a big bug and I've delisted it from nuget. So the official version is 1.7. :(

Second, see this: https://github.com/mccalltd/AttributeRouting/wiki/Using-AttributeRouting-Outside-of-Web-Projects. If updating your assembly bindings doesn't work, then let me know and I'll start digging into it.

Thanks!

[RobARichardson]

Thanks for the quick response!

I reverted back to v1.7, and then added the bindings to the test project's App.config but I'm still getting the same results :(

[mccalltd]

Dang! I'll look into it tomorrow. Sorry for the problems.

On Apr 20, 2012, at 8:30 PM, Rob Richardson [email protected] wrote:

Thanks for the quick response!

I reverted back to v1.7, and then added the bindings to the test project's App.config but I'm still getting the same results :(

---

Reply to this email directly or view it on GitHub: https://github.com/mccalltd/AttributeRouting/issues/64#issuecomment-5256370

[RobARichardson]

Cool, thank you!

[kamranayub]

Weird, don't we do this in the actual unit tests as well? The actual scanning code does this:

return from type in assembly.GetTypes()
                   where !type.IsAbstract && controllerType.IsAssignableFrom(type)
                   select type;

controllerType in your case would be Controller.

[mccalltd]

Yeah. This is a weird exception. The MSDN docs say: "The exception that is thrown when the security policy requires code to be type safe and the verification process is unable to verify that the code is type safe." I'm not sure where security policy would come into play.

In addition, checkout out this test, which does exactly what you are doing.

Could you check out the example and let me know if your test code is different in some major way?

[kamranayub]

Is this a medium trust or some other low trust environment? I guess I haven't deployed my app using v2 yet to my host so I am not sure if trust level is coming into play here.

Is this just happening locally?

[RobARichardson]

Hey guys, I just tried my tests again this morning and the routes are now getting added to my route collection properly with no issues. When I added the bindings to the App.config last night and it didn't work, I think it must not have picked up the changes immediately because pulling out the bindings now will immediately trigger the same issues again. So anyway, my sincere apologies for the false alarm. Thanks for your help.

[mccalltd]

Glad to hear it's resolved.

On Apr 21, 2012, at 11:21 AM, Rob Richardson wrote:

Hey guys, I just tried my tests again this morning and the routes are now getting added to my route collection properly with no issues. When I added the bindings to the App.config last night and it didn't work, I think it must not have picked up the changes immediately because pulling out the bindings now will immediately trigger the same issues again. So anyway, my sincere apologies for the false alarm. Thanks for your help.

---

Reply to this email directly or view it on GitHub: https://github.com/mccalltd/AttributeRouting/issues/64#issuecomment-5262049

[duyker]

Hi, I have recently encountered this same problem using VS2012

Microsoft Visual Studio Premium 2012
Version 11.0.50727.1 RTMREL
Microsoft .NET Framework
Version 4.5.50709

AttributeRouting Version 3.1.3

It seems to be a similar issue to what FluentMVCTesting is having:

https://github.com/robdmoore/FluentMVCTesting#known-issues

I resolved this by:

1. installing Install-Package AspNetMvc on AttributeRouting and recompiling.
2. referencing manually compiled version of AttributeRouting.
3. installing Install-Package AspNetMvc on my own application and recompiling.

p.s - I have code that recreates this issue if you would like a copy.

[mccalltd]

Thanks for the info. I'm going to have to have two versions of the AttributeRouting.MVC nuget package it seems; one for MVC3 and one for MVC4. Currently the Web API stuff references the web api packages. So ideally the MVC stuff would do similarly.

[duyker]

Awesome, thanks for that (sorry for the late reply)

[jupaol]

Is there a workaround for this? I'm using Visual Studio 2012 Ultimate and AttributeRouting 3.5.6 MVC 4 and I still have the same issue

If there's another way to load the routes into memory to be able to test them?

[julian-maughan]

I solved this by adding a binding redirect to my unit-test project configuration file (App.config):

  <dependentAssembly>
    <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.0.0.0" />
  </dependentAssembly>

The AttributeRouting.Web.Mvc assembly (v3.5.6) has a dependency on System.Web.Mvc version 3.0.0.0. The redirect is required if you are using a more recent version. It will most likely already be in a web project's Web.config, but not so likely in the App.config of a testing class library project.

[JorgeMCSilva]

Is there a date for this issue to be solved? I added the redirect on app config but that didn't to anything.

Cheers, J