The hard journey of deploying MVC5 templates in VS2013 to mono

Deployment environment: CentOS7 + Mono 3.10 + Jexus 5.6

The ASP. NET project created in Xamarin.studio, the deployment process is very smooth, no problems encountered, but the ASP. NET project created in VS2013, the deployment process will have some twists and turns. Now think about it because the project template in Xamarin.studio is relatively simple, just showing a few words and not using anything in MVC5.

VS2013 create a new ASP. NET project (the target framework is. net4.5), select MVC, and change authentication to not apply authentication.

Compile, and publish to the directory that the Jexus default site points to, access it. The reported error message is as follows.

According to the exception stack information, should be called HtmlHelper's ActionLink method, the helper used the routecollectionextention to obtain the virtual path method, the problem is in this method.

Look at the hint should be routecollection less appendtrailingslash this attribute (bool, used to control the conversion to the virtual path when the last add "/").

In fact, the code for the ASP. NET Routing framework is in System.web.dll, and System.Web.Routing.dll is a blank assembly with no code. Routecollectionextention is a series of extension methods in MVC that routecollection in the routing framework for ease of use.

Open the MVC routecollectionextention source code (http://aspnetwebstack.codeplex.com/SourceControl/latest#src/System.Web.Mvc/ RouteCollectionExtensions.cs), the Appendtrailingslash call to RouteCollection was found.

Comparing the RouteCollection classes in. NET and mono, it is found that the Appendtrailingslash attribute is not implemented in mono, and there is no lowercaseurls this attribute (the code address is, respectively. net:http:// referencesource.microsoft.com/#System. web/xsp/system/web/routing/routecollection.cs#8f054052ef9931ac# references,mono:https://github.com/mono/mono/blob/master/mcs/class/system.web.routing/system.web.routing/ RouteCollection.cs).

Take a look at the last update time for routecollection this file in mono, + +, two years ago, OK.

Since properties cannot be extended like extension methods, and there is no abstraction for routecollection in the route, it is a direct reference to the routecollection, which I have no time to recruit. All over Google, only questions, no answers.

You can only go around, find view/share/_layout.cshtml, comment out the code that calls Html.ActionLink, republish.

This is normal access, but the page style is messy, in the browser developer tool can see the following 404 information, because the bundle framework is certainly not working.

The solution is to Find the Bin folder to delete Microsoft.Web.Infrastructure.dll, because Mono has its own implementation of this Assembly in Lib, for development and deployment convenience, you can also directly set the Microsoft.Web.Infrastructure.dll to not Copy to Local.

Re-visit, you can see the fresh bootstrap interface, just a few unlucky links on the menu is commented out.

The above know, mono at present MVC5 compatibility is not good enough, may be in such vnext disdain compatible mvc5 it.

MVC5 It is not a problem to display several words on mono, but htmlhelper some methods cannot be used because they indirectly invoke the properties of a routing framework that is not implemented by mono.

The method of obtaining virtual path in Routecollectionextention is very important and frequently used, for this, can only discard mvc5, downgrade it to Mvc4.

The process of demotion is a history of tears, Blood, tears, and excrement. The MVC-related NuGet packages are: Microsoft ASP. NET MVC, Microsoft ASP. NET Web Pages, Microsoft ASP. Razor, which is not necessarily compatible between the different versions of these three packages. Originally wanted to be directly in NuGet to introduce MVC4, but encountered a variety of problems, not the package is less a method is that package less method, eventually tried a lot of combinations and did not succeed.

Finally had to use an opportunistic approach, first create a MVC4 project (in vs2013 in the Create Project box expand the Web Select vs2012 can see Mvc4 template), and then the VS auto-created Mvc4, webpage, razor package, Copied to the original solution's package directory.

In NuGet, uninstall MVC5, webpages, Razor, and then add a reference to the assemblies in the three packages that you copied above, and you will encounter the following exception in the compilation run in vs2013:

Open the View folder under the Web.config,configsections still retains a reference to the first few assemblies, the MVC4 project in the configuration copy, compile run, and see the following exception:

Can not find the System.Web.Helpers namespace, I clearly quoted the System.Web.Helpers this Assembly ah, but the bin actually did not System.Web.Helpers.dll. Look carefully, the original is not set to copy to the local, the corresponding check the above manually added a few references are set to copy to the local, compiled again run, under Windows has been able to browse the normal.

Uncomment the code that was commented out in the above layout.cshtml to call Html.ActionLink.

Compile and run, OK, deploy to CentOS, Delete the Microsoft.Web.Infrastructure.dll in the Bin folder, restart Jexus, browse it, normal display, click on the menu through HtmlHelper generated several connections, perfect!!! The unlucky menu is back!!!

The final code is here.

The hard journey of deploying MVC5 templates in VS2013 to mono