Site die when deploy a developing module

[CissSolution]

Dear friends, when developing module, if I deploy a module that cause error to the main process when restart Oqtane , then the site die and difficulte to recover. Consider in real situation, if a module of third party has conflictions or else that make a live Oqtane site die, it might make developer reluctants to choose Oqtane as a steady solution for customers. Unlike DNN has very stable install process thought. Please consider this in next update

[sbwalker]

@avman20 this is not something that can be "fixed in an update"... as it is not a behavior which is controlled by Oqtane. There is a major philosophical difference between the .NET Framework (legacy) and .NET Core (modern).

When using .NET Framework it was common practice to silently suppress errors and allow the application to continue to run in an "unsupported" state. This created the "perception" of a stable environment but could often result in many types of undesirable scenarios (ie. data corruption, unexplainable errors, etc...). The .NET Framework also relied on dynamic techniques for object creation, data access, etc... which are more forgiving at run-time, however also have the downside of being less secure and exhibiting poor performance.

When Microsoft created .NET Core ~10 years ago, the approach was to "fail fast" when there are system level issues identified. This is to protect the system from operating in an "unsupported" state. It relies on static, type-safe techniques which are less forgiving, but have the advantage of being more secure and exhibiting higher performance. This approach is the dominant approach across all current enterprise software development platforms and is aligned with the deployment philosophy of modern infrastructure.

The challenge you are experiencing is that if you are coming from a .NET Framework background, you are accustomed to using a development approach which was aligned to the characteristics of that platform. When using .NET Core you will need to embrace the new behaviors. In practical terms this usually means adopting new strategies for development, testing, deployment, etc... From an Oqtane perspective, the Oqtane.Server\Content\Log\error.log is very helpful for understanding exceptions which occur during .NET Core startup.

[sbwalker]

@avman20 to more specifically address some of your points in your original post, there are only specific types of conflicts in a third party module which will affect the entire Oqtane installation. A conflict in a razor component will usually be handled automatically and the UI will display a friendly message to the user. A conflict on the server in an API or Repository (ie. a model which does not match the database schema) will not be handled as gracefully and may result in an unfriendly general exception for the entire application. During development this may occur more frequently as you are changing the code frequently and sometimes make mistakes. In a production scenario, you should always test the application thoroughly before deployment.

[CissSolution]

Thanks for answer quickly, that clarify things. Eventhough it could be nice if more error prevention mechanisms applied in future.