定義済み)という風に、構成がドンドン増えていってしまいます。android_debugandroid_releaseandroid_trial_debugandroid_trial_releasesteam_debugsteam_releasesteam_trial_debugsteam_trial_releaseの8構成があることになります。体験版の制限に必要な変数や仕組みを仕様としてあげそのソースコードに製品版のコードも一緒に組み込みます。綺麗にいけばいいですけど、やっぱり所々でソースコードがちょっと汚くなってしまうこともあります。さんのやり方は組み合わせの問題で爆発的に管理するものが増えるのでたしかに困ってしまいますね。限定公開も、制御する変数を用意し、それを使って限定公開するものを作成します。参考になるかわかりませんが、私の場合は仕様書を先に作っておきます。5ヶ月前ありがとうございます。マクロではなくて変数で切り替える、という感じですね。私も変数で切り替えるのがベターだと思います。読み込ませるデータファイルによって振る舞いが変わるという感じですかね。製品版のデータが入っているフォルダにEXEを入れれば製品版として動作するし体験版のデータが入っているフォルダにEXEを入れれば体験版として動作みたいな?私一人に限っていえばそうなります。他の方はどうやっているのかも知りたいところですね。5ヶ月前ゲームではないですが、他の製品で製品版と体験版を作ったことがあります。基本方針は、dicさんが書かれているような、変数を使って動作を変えるというので変わりはないですが、その変数を設定するメインを含むexeのプロジェクトを、製品版と体験版で別々に作りました。すると、実際のアプリケーションの処理は、exeのプロジェクトに入れるとメンテナンスが面倒だったので、それらはライブラリ(dll)へ分離し、exe側から参照するような仕組みにしました。main(){application(true);}application()がゲームアプリケーションのエントリーポイントで、試用版のmainからはtrueで呼び出し、製品版ではfalseで呼び出すといった感じです。applicationの本体は、別のライブラリプロジェクトに入れておくと。5ヶ月前ありがとうございますなるほど、ソリューション構成ではなくプロジェクトごと切り替えれば良いってのは確かにその通りですね。exeのエディションとデータファイルのエディション不一致によるエラーも起こりませんし、プロジェクトを切り替える方式ならソリューション構成を増やさずにビルドオプションを切り替えたりする事ができますね。ミクプラは自由にリンクできます。