From. Net to mono-note the compatibility of kooboo CMS to mono: 3. platform compatibility

From. net Framework migration to the mono platform, in addition to frequent case sensitivity issues, but also often encounter some platform incompatibility problems, this is also my experience, another troublesome problem. In fact, the compatibility of the mono platform has been released in the official documentation, and they will clearly describe mono compatibility in one sentence:"Everything in. Net 4.0 running t WPF, entityframework and WF, limited WCF .". But it's not that simple! In kooboo CMS, WPF, EF, WF, and WCF are not used at present, but there are still several problems caused by platform compatibility. These incompatibility are the intent of Mono design. Due to the differences in the operating system platform, Mono may choose to be incompatible with some functions. I also encountered some problems.. NET FrameworkCodeBut it cannot be compiled in mono, which may be different in the rigorous design of the compiler. At the same time, for supported APIs, although the functions are indeed supported, but we will still get some.. NET Framework does not have the same results and causes incompatibility.

ForProgramWhen the set is incompatible, the mono policy is better, unlike the various sets that often occur during startup of. NET Framework, which cannot be loaded and the whole site cannot be started. We can directly put the compiled web site in. net into the mono runtime for execution. At this time, if your program uses some assembly or APIs not supported by mono, it will not immediately tell you that the program cannot be started, but as long as you have not used these functions, the program can run normally. Therefore, we often find that the released sites can run directly in mono. However, when we open the source code with monodevelop, it cannot be compiled, causing many compilation errors. I like this design very much.

However, debugging is essential for ASP. NET sites to be fully compatible with mono. Therefore, we must ensure that our source code can be opened in monodevelop and fully compiled. The following problems are found and solved through monodevelop debugging after incompatibility, compilation, or program errors. Let's take a look:

2. ASP. NET healthmonitoring is incompatible. After the source code is opened with monodevelop, many errors are found during compilation. Most of the errors occur on several healthmonitoring classes that have been rewritten. Many studies have found that mono has only a few classes in the space of system. Web. Management, and most of these classes have no specific implementation. This is not compatible. Naturally, there is nothing to say, and there is no good solution, so we can find a good alternative. However, I believe this function can be implemented. Apart from EventLog's systematic platform features, there should be no more platform dependencies.
4. In the compilation error, there is a line of code that runs normally in. Net but fails in mono, prompting us to perform type conversion. To better illustrate this compilation error, I extracted the code prototype:

   Public interface ireadonly {string name {Get;} public class baseclass {public string name {Get; Set ;}} public class class1: baseclass, ireadonly {} class mainclass {public static void setname <t> (t o) where T: baseclass, ireadonly {o. name = "";}}

   In this Code, the line "O. Name =" "will prompt" ambiguity between baseclass. Name and ireadonly. Name "in mono ". For this problem, the solution is very simple. You only need to perform type conversion for O, convert it to the baseclass type, and then assign a value. I don't know much about compiler behavior, so I can't explain it. It can only be said that the two compilers differ in type processing rigor.

5. For the APIS supported by mono, we still need to run the test to ensure that it works properly. It is easy to understand that the same API, different platforms, produces different results. I have two such problems.
   • When keyedhashalgorithm is used, the hash results for strings are different. Because keyedhashalgorithm is used to encrypt the user password once, but the same user data and the entered password always prompt that the password is incorrect when mono runs. After debugging, it is found that the key length is different between. NET and mono, but the key length is only used. We only need to make them use the same length, and add this line of code: algorithm. Key = new byte [64];
   • I used datacontractserializer to serialize objects. When serializing common objects, their formats are consistent. However, when serializing a dictionary object, there are some differences between. NET and mono. These differences are mainly concentrated in the XML namespace. In. net, the name space of the serialized root node is bytes. This makes data switching between platforms incompatible. However, after a period of research, we still find a solution. You only need to specify the method when instantiating datacontractserializer. net root node namespace can solve the problem:

      datacontractserializer SER = new datacontractserializer (typeof (list 
           
            ), "arrayofarrayofkeyvalueofstringanytype", "http://schemas.microsoft.com/2003/10/Serialization/Arrays", new type [] {typeof (Dictionary 
            
              )}) 
            
           

     for serialization incompatibility, another problem is that mono and. NET is still somewhat different. In. net, the property of an object contains an idictionary object that can be normally serialized and deserialized. However, the message "'I' type cannot be an interface itself" is displayed during Mono operation ". The solution to this error is to change idictionary to dictionary and use a specific type instead of an interface.

The above problems are all the platform incompatibility problems that I can remember at present. As you can see, apart from functions and APIs not supported by mono itself, other compatibility problems can still be solved smoothly after a period of debugging and research. Therefore, I believe that to make a common ASP. Net Site compatible with mono, it should not only exist theoretically.

Originally planned, this article was written as an end article. However, during the writing process, we found that some other experiences were missing, such as monodevelop experience and ASP. net mvc program debugging experience. These are different from those on the Windows/. NET platform. So I will share and record my experience in this area in the next article.