Linuxでのオンラインオフィスへの最初のステップ、またはMonoへの移植方法(困難とそれらを克服する方法について)





昨日、LinuxでONLYOFFICEをリリースしました。ニュースだけでなく、5年前に「ASP.Net」と呼ばれる独自のtrapに陥った人々のために役立つ情報も急いで共有しています。



4年前、Monoプロジェクトを使用してアプリケーションをUnixに移植する試みを始めましたが、.NetからWindowsへの移植時にMonoの機能が大幅に遅れていたため、長い間成功しませんでした。 特に、Monoでは、wcfサポートが大幅に削減され、asp.net mvcもうまく機能しませんでした。 ただし、幸いなことに開発者はここ数年、Monoプロジェクトを積極的に開発しており、.Net 4.0と.Net 4.5のサポートが追加されたため、2013年春に作業を再開することにしました。



ここでは、クラウドオフィスをMonoに移植する際に発生した問題、それらの決定方法、最終的な結果、1人のプロアクティブユーザーがリリースから2時間後にDockerfileにすべてをラップする方法について説明します。



Monoに移植する際の主な問題





1.ファイルシステムを操作する



何が起こるか:サイトが開かず、画像が表示されないか、正しく表示されません。 現在、問題 Monoプロジェクトの公式Webサイトで詳細に説明されています。



問題: Windowsではスラッシュとバックスラッシュは同じものであり、Unixでは2つのまったく異なるパスがあります。 Windowsではパスは大文字と小文字を区別しませんが、Unixではパスは異なる名前です。

問題を解決する方法:



2.非終了トランザクション



何が起こるか: MySQLデータベース内の非終了トランザクション。

問題:残念ながら、彼らは最後まで見つけられませんでした(仮定はありますか?)

決定通り:接続文字列AutoEnlist = falseにパラメーターを追加しました



3. xml Monoシリアライザーの動作の違い



何が起こるか: xmlで空の名前空間を使用すると、モノシリアライザーでnull値と例外を持つフィールドのxml表現の違い。

決定方法:ドキュメントモジュールのwcfサービスを削除し、webapiに置き換えました。



4.メモリリーク



何が起こるか: apache2にmod_mono_serverを使用するとメモリリークが発生します 。 たとえば、既にキャッシュにあるキーを使用して新しいデータをHttpRuntime.Cacheに挿入すると、Monoは.NETとは異なり、以前のデータが占有していたメモリを解放しません。

問題は何でしたか:まだ謎です。

決定通り:この問題を解決するには、新しいデータを挿入する前に古いデータを明示的に削除する必要があります。 次に、nginxに切り替えましたが、同様の問題は見られませんでした。



5. NullReferenceException



何が起こるか: WCFサービスで、ConfigurationManagerクラスのメンバーにアクセスするときに、以前にHttpContext.Currentプロパティをどこかに書き換えていた場合、NullReferenceExceptionが発生しました。

問題:非WebアプリケーションでHttpContext.Currentを手動で設定すると、monoはConfigurationManagerではなくWebConfigurationManagerの使用を開始します。これにより、非Webアプリケーションで例外が発生します。

決定通り: HttpContext.Currentの手動インストールを取り除きました。



6. MicrosoftバージョンとHTTP WCFの非互換性



問題: HTTP WCF Monoサービスには、Microsoftバージョンと比べて多くの小さな違いがあります(たとえば、シリアル化中のxmlのわずかな違い。monoバージョンでは、拡張機能は属性ではなく構成ファイルのみで指定できません。HttpContext.Currentなどはありません) 。

あなたが決めたように: Web APIに基づいたバージョンのWCF HTTPドキュメントサービス書き直しました。



7.負荷テスト中にSignalRサーバーがクラッシュする



問題:ページに埋め込まれたチャットでメッセージを送信するとき、ASP.NET SignalRライブラリを使用します。 ONLYOFFICEをMonoに移植する場合、このライブラリも使用したいと思います。 データ転送のためのいくつかのタイプのトランスポートをサポートします:websocket、ロングポーリング、永久フレーム、サーバー送信イベント。 私たちにとって最も望ましいのは、Saasバージョンで使用しているWebソケットの技術です。 残念ながら、現時点では、SignalRはMonoでのWebソケットの使用を許可していないため、ロングポーリングをトランスポートとして使用する試みが行われました。 しかし、負荷テストの段階で、SignalRサーバーはSystem.IO.IOException:「Too many open files」を除いてクラッシュしました-約1000のクライアント接続の後。 問題をさらに調査すると、SignalR開発者に報告したクライアントの切断後、SignalRサーバー上のソケットのリークが確認されました。 SignalRの次のバージョンで、この問題が解決されることを願っています。

決定したとおり、他のトランスポートはさまざまな理由で問題を解決するのに適していないため、Monoバージョンでは、SignalRを使用してチャットをオフにする必要がありました。



合計でプロジェクトに数百の変更が加えられましたが、結果として、同じソースからビルドするときに、Monoを使用してWindowsとUnixの両方で正しく動作するバージョンを作成することができました。



合計で何がありますか



最初のONLYOFFICEページがMonoで公開されてから6か月が経過しました。 現在、プロジェクトとドキュメントを管理し、顧客ベースを維持するためのクロスプラットフォームソリューションがあり、メールアグリゲーターやコラボレーション用のその他のツールによって強化されています。







製品の著作権保護として、 AGPL v.3ライセンスを選択しました。つまり、チームの内部作業にのみONLYOFFICE Commonを展開できますが、独自のプロジェクトのソースを使用して、同じライセンスでコードを開く必要があります。



Dockerトレンド



バージョンのリリースからすでに数時間後、イニシアチブユーザーからのメッセージが開発者フォーラムに登場しました。彼は私たちよりも先にあり、Dockerfileでソリューション全体をラップすることができました(ありがとうございました)。



このアセンブリはまだ作業する価値があるという事実にもかかわらず、傾向は正しく推測されています-近い将来、各配布言語用にONLYOFFICE Dockerコンテナを準備する予定です。



Linuxオンラインドキュメントエディタ-近日公開



ONLYOFFICEドキュメントエディタのバックエンドのほとんどはC ++で記述されているため、Linuxでのアプリケーションの翻訳は他の方法を使用して行われます。



たとえば、最近、ドキュメント形式の変換を担当する要素での作業を終了しました。 ここでの主な問題は、ActiveXおよびATLコンポーネントを取り除くことです。



計画を実施するには、4つのステップを実行する必要がありました。



当面の計画には、一般的なOS向けのデスクトップオフィスアプリケーションの開発が含まれているため、ビルドにはQt Frameworkのqmakeを使用しました。 さらに、QtCreator IDEはコードの開発とデバッグに最も便利なオプションのように思えました。



* * *



今日、製品開発を開始した場合、もちろん、ONLYOFFICEの移植プロセスの終わりに発表されたASP.NET vNextを使用します(開発の不公平な世界!)。 しかし、問題はすでに完了しており、計画はいつものようにナポレオンです。 来年、Linux向けのオープンなオンラインオフィスをリリースします。これは、OpenOfficeを自社の領域で最終的に活用できることを意味します。 ただし、これはまったく異なる話であり、1月に詳しく説明します。



それまでの間、私たちのチームは皆さんに明けましておめでとうございます!

追伸 休暇中にすでに休暇中だがオフィスにいる人は、写真のすべてのペンギンを数える時計を渡すことができます(従業員は数えません)。










All Articles