From. Net to mono-note the compatibility of kooboo CMS to mono: Second, Case sensitivity issues, where mines are everywhere

In Linux/Unix systems, processing of any file path, file name, or URL address is case sensitive. For this design, we have been engaged in development and work on Windows platform for a long time. Although this design may have a special purpose and starting point, I still think it is a very painful design. I tried to find some reasons to explain why Linux uses case sensitivity to handle these strings, but the answer is a bit irrelevant:

• After being case sensitive, you can use a shorter file name to indicate more files. For example, a.txt and a.txt files are not the same, but they are case-insensitive and can only represent the same file.
• It is case sensitive and makes it easier to sort strings (file names.
• Linux is written in C language. In C language, strings are case sensitive. Isn't c ++ and C # case sensitive?
• Uppercase and lowercase characters have different ASCII values. Should they be considered different characters?

In the above discussion, is there a reason to become a scapegoat for the inconvenience caused by Case sensitivity (please allow me to comment on this design from the perspective of a Windows User )? In my cross-platform research experience during this period, this problem is no longer an inconvenient problem. It has risen to a major issue in the software compatibility layer. You can say, we write this by ourselves.ProgramRandom. However, for developers who have been developing on the Windows platform for a long time, how many programmers will notice that the file path and file name are case-insensitive. In my problems, at least 80% of the above problems are caused by inconsistent file names and path case sensitivity, sometimes it takes quite a long time for debugging to be noticed. Let's take a look at the software compatibility problems caused by Case sensitivity that I have found so far:

• When the homepage is opened, you will find a 404 error. If you are lucky, check whether index. aspx is written as index. aspx.
• When you open the page, you find that the page style is messy, and it is not our normal display effect. Then we may need to use firebug or other HTTP network request checking tools to see if there are any style request errors and whether l is written as l.
• After you solve the style problem, you may still have many images and the logo cannot be properly displayed. If the access is normal under Windows, your first response should also check the case.
• The same problem occurs in the request script file.
• If you have file read/write operations in your program, 80% may run abnormally, and the same is caused by inconsistent file names (paths, important check is required.
• We use MVC. Most often, the URL, Controller, and view names exist in an agreed form, and vs provides a good scaffold, let's make sure that the case sensitivity of the controller and view are basically the same, but is that enough? In such requests, you may often receive exceptions that cannot be found in various views. In the first response, you should check the file size and path size. But to solve this problem, it is not solved by modifying the program. Suppose there is a view of accountcontroller. in windows, we can request a normal view through account or account, but in Linux, you cannot request a normal view through account. The request cannot be processed normally, not because the controller is not case sensitive in MVC. However, because you request an account, it considers the controllername to be an account, and uses the account string to find the corresponding view. Assume that our original view is an account, at this time, it will definitely find an error. There is basically no good way to solve this problem, either from the underlying iomap, or by forcing the URL to be case sensitive.
• In MVC, there is a metadata called uihit, which can be used to specify the template for editing a field. Here, we assume that uihit ("password") is used, but password. cshtml exists in editortemplates, which also leads to the illusion of CSS compatibility problems on our pages.

Fortunately, the CSS and JavaScript syntaxes are case-sensitive. Otherwise, it will be much more painful.

As mentioned above, the mono team has long realized that if they do not solve these cases, they may be an obstacle to the better development of Mono. Therefore, they provide an underlying ing called iomap to prevent compatibility problems caused by different file paths. However, in the introduction, we only mention the Apache-based configuration example. There may also be support examples for xsp:

Mono_options = "-- debug -- profile = iomap" xsp2

However, because I need to debug more other problems in monodevelop, I also need to enable the iomap option when monodevelop starts site debugging with xsp. Unfortunately, so far, I have not set a method. Tonight, I saw that mono tools for Visual Studio 2.0 Beta 1 debugging can configure this option, but why does this mono_tools support cross-platform debugging? Isn't it just a Visual Studio plug-in? Maybe the mystery is here. I hope that I can solve the problem of using iomap during debugging in a few days. This can really reduce the numberCodeChanged

 

This article ends

About the debug case of monodevelop official email list discussion: http://go-mono.com/forums/#nabble-td3606760