From. Net to mono-note the compatibility of kooboo CMS to mono: 1. Basic Considerations for mono and migration platforms

Preface

Mono is a very interesting platform that providesProgramThe possibility of cross-platform migration is a technology that seems to be able to crush the criticism of. NET platform software without cross-platform questioning. I like the. NET platform very much. At the same time, I also hope that it can meet various needs, including cross-platform features. Therefore, I am also very interested in Mono technology. I have been engaged in the development of CMS open-source projects for the past two years. Driven by the convenience of work and interest in technical research, I have always hoped that kooboo CMS can support running on the mono platform, and further let more people know about Mono and kooboo CMS. This is one of my few clear technical goals in recent years.

Kooboo cms3.0 was completely rewritten last year.CodeIncluding the architecture. In this rewrite process, many more cross-platform considerations are added based on smaller permission requirements, less dependency on system resources, and less dependency on third-party assembly.

• Smaller permission requirements: When I was writing code, I did not consider the code running security issues. No matter what technical means are used, enabling the program to run properly is the only goal. Therefore, I often use code that requires a high level of Code Trust. For example, emit, System File Operations, unlimited reflection code, Recording System Event Logs, and many other code operation permissions that require full trust level. This kind of code will limit the space of the program in the host, and even cause the project to be unavailable to a large number of users. On the other hand, I think code that requires a higher level of trust may cause more trouble in cross-platform migration. Therefore, it is more helpful to support the mono platform to limit the code to the smallest possible drag-and-drop scope. After all, Mono does not fully implement all. NET functions.
• Less dependent system resources: this is even more obvious. When we use functions and APIs with System Platform features, we may have to give up the migration because of the lack of a function or API. In another example, we are used to development on Windows. Many of us use "\" to split or merge file paths, however, when your code contains a large number of such potential rules, it will cause greater trouble for our migration work.
• Less dependent on third-party Assembly: whether or not this requires migration, it is also very important for common development. When you rely on a lot of third-party assembly, when one of them does not have cross-platform features, it is very troublesome.

Despite the full consideration made at the beginning of the design, there are also some planning. However, my recent practical experience tells me that from. Net to mono is definitely not easy and easy. You may encounter various unpredictable problems. On the one hand, it may be because the mono platform does not have a large number of success stories and full testing and use, and every user may find problems and bugs that others have never encountered before; on the other hand, because of the features of different system platforms, Mono cannot be used with common systems for compatibility or other considerations.. NET environment is not the same as the configuration environment, so that our program runs wrong. Even so, I have already finished half the journey. So far, I have been able to successfully run kooboo CMS on mono + linux, in addition, most basic tasks can be done. There are still some problems that cannot be solved by me, but it may take a long time.

This record process is a simple record in the form of Weibo, but I believe that the blog effect will be more convenient and systematic than Weibo in order to make the knowledge better summarized and disseminated. Therefore, I plan to summarize my migration experience from time to time, I hope this summary process will give me more motivation to study and solve various problems encountered in Mono (currently in the status of intermittent interruption ). Today, we will briefly summarize some basic precautions for mono platform. NET development. (In addition, it should be noted that only the mono migration of ASP. NET is concerned here, and does not involve the mono support of winform, sivlerligh, and WPF .)

Basic notes

In this article on the mono official website, guidelines: application portability provides a general introduction to some important points that need to be paid attention to during migration from the development of the Windows platform to the Linux platform. We have briefly introduced these points:

• Case sensitivity. This is the first and most frequently encountered problem. Although I have reminded myself more than once that all strings under liunx are case sensitive, including file paths, I am still not on this issue. It is often because the request for a style or script is invalid. I am still checking whether there are any parsing problems. However, after dozens of minutes, we found that a character in your path is case-insensitive. In my opinion, the Linux path is really case-insensitive, no matter what the use of IT, windows is not case sensitive ??
• Path separator. As mentioned above, "\" is directly used in the code to split or merge paths. Here, this situation should be absolutely eliminated. The system. Io. Path class provides many APIs to help us solve these problems. Please try to develop the habit of using this class.
• Absolute path: in Linux, the expression of absolute path is different from that in windows. Therefore, try to use some static system APIs to solve these problems.
• P/invoke, which is absolutely not allowed. For the Win32 API you call, the running platform on which it depends cannot be called across platforms.
• Registry operations. Likewise, this should not happen.
• For the control of the underlying computer commands, We Should almost never write. net programs, skipped. (I don't know if the Il code can be cross-platform? Maybe not .)

In short, all of its requirements are to follow the Features shared by all platforms, and try to avoid using code with clearly specific platform features. In addition to the features that are obviously not supported in the official mono documentation, we will also encounter some technical details that are not mentioned or cannot be implemented, I encountered some problems, including the key length and encryption/decryption of the class library. the encryption/Decryption fails (solved) because of different net values. The healthmornitoring function is not supported. The deserialized format of datacontractserializer serialization is inconsistent (which is still not resolved ); compilation failure caused by inconsistent compilation of some language features.

For compatibility of the mono platform, we can refer to the compatibility document, but the compatibility of some features has changed in the new version. For example, in 2.10.2, mvc3 compatibility has been completely solved. For API compatibility, we can get to know through this link: http://www.go-mono.com/status.

About debugging

If any problem occurs when we directly run the program compiled with vs to mono/Linux, we cannot simply use its exception message to get the cause of the problem. If the same function appears in windows and mono/Linux fails. In addition to debugging, there is basically no better way to troubleshoot the error. Therefore, we are ready to debug the program in Mono/Linux. Maybe the only option is to run the program through monodevelop in Linux. This is the simplest method at present. Here, we need to know that a program compiled in vs can be run directly in Mono/Linux without any problems. However, if the code of this program is to be compiled using monodevelop and mono runtime, you may not be able to easily pass through it. However, don't worry, as long as we solve those compilation errors and use monodevelop + xsp for debugging, the user experience is good.

This article ends