Windows」カテゴリーアーカイブ

MSBuild

Visual C#がインストールされていない環境で、WindowsだけでC#の開発を行う方法について

からなんかウチのネタ元ページにチビチビと人が来ている。
いや、プログラミングに興味を持つ人が増えるのならキッカケなんて何でもいいと思うけーが…
しかし画像だらけで私的にはゲンナリするけど今時の人はこんな感じの解説を望んでいるのかな?
まあそれは関係なくて。

つまり
カレントディレクトリに sln か csproj があれば msbuild コマンドでビルドができるわけです。

単発小物なら csc コマンドに直渡しのほうが簡単だけど少し複雑になるとコッチのほうが楽。
csc コマンドでは XAML のビルドはできないけど csproj を使えば可能になる。
絶対に Visual Studio なんか使いたくないという意地っ張りなところが素敵な人もいる。
GNU make のように利用したい Linux 脳丸出しな人もいる。

ということで、実は MSBuild ならもっとイイ方法がある。

.NETビルド・エンジン「MSBuild」使いこなし術 ? @IT

上記に手段が書いているけど環境変数は単一インスタンス内で追加できる。
何かする毎に環境変数を書き換えるなんて面倒だからその方法を利用する。

実は msbuild コマンドのみでカレントディレクトリの sln, csproj を勝手に見つけてくれる。
GNU make の Makefile と同じ、つまり引数は不要。

MSBuildToolsPath って何?
MSBuild で特定の .NET Framework を対象にする
よく解らないけど WPF はこの指定が無いとビルドできなかった。

と、これだけ理解できれば EmEditor 等の外部ツールで MSBuild が使えると解る。

GNOME 上で Gedit を使い C, Makefile を作成し Ctrl+F8 を行うのと同じことができます。
解説が逆だろと言わない、筆者のメインマシンは Fedora です(Windows7 はミニノート)

残念なことに秀丸や EmEditor は複数行の外部ツールは使えないので bat を作って利用する。
複数行コマンドが利用できるエディタ(あるのか?)なら bat の内容を直書きでいいと思う。
で Windows7,8 に最初から入っている .NET 3.5 を使う手段まで。

一応書くとこのミニノートに Visual Studio は入れていません。
環境変数もデフォルトの状態に戻し再起動を行った状態で以下をやってみる。

@set PATH=%PATH%;%WINDIR%\Microsoft.Net\Framework\v3.5
@set MSBuildToolsPath=%WINDIR%\Microsoft.NET\Framework\v3.5
msbuild
pause

という内容で build35.bat みたいな名前でバッチファイルをまず作成。
.NET 4.0 を使うなら 3.5 を 4.0.30319 に変えて build40.bat なんかに。
これをテキストエディタの外部ツールに登録する。
下記は EmEditor の例、カレントディレクトリの指定に注意。

emediter_set

秀丸なら [プログラム実行] に bat へのフルパスを書き込むだけ。
フルパス取得には minipoli でも使ってくださいw
その他エディタは知らない、まともなプログラマーならこの二択もしくは両方だし。

登録したら MSDN のサンプルコードで試してみよう。
チュートリアル: MSBuild プロジェクト ファイルのゼロからの作成

コピペで helloworld.cs と test.csproj を作成。
helloworld.cs をエディタで開いている状態で外部ツールを実行。

build

普通に exe が作成されるのが解りますね。
日本語を使うなら cs, xaml ファイルはすべて BOM 付き UTF-8 で保存してください。
csc は BOM が無い場合はローケルと同じ文字コードとみなすはずですけど一応。

WPF だと構成ファイルや csproj が超複雑になるので zip で置いておく。
[SDK が見つからない] 警告を出さない方法は残念ながら解らない…
wpf_csproj.zip

VC# を持っているなら csproj と同じディレクトリにある C# コードを開いて外部ツールを実行すればビルドできると確認できる。
これで環境変数すら弄くらなくてもテキストエディタから一発ビルドできる環境の完成。

MSBuild
しかしそのプロジェクトファイルが複雑すぎて手書きで作るのが面倒くさい!
proj ファイルを簡単に作るジェネレータとかどこかに無いかな。

Microsoft としては Visual Studio を買ってほしいのだろうけどさ。
プログラミングに慣れると IDE なんて鬱陶しいだけなんだって。
普段使っているテキストエディタのみ、かつ環境変数すら弄くらないことに意義がある。

それって…
結論、やっぱり Linux で Python のほうがイイ。

Celeron su2300 mini Note @ Fedora Dual Boot

Acer Aspire 1410 ミニノートの電源を三ヶ月ぶりくらいで起動。

当然のごとく二時間半程度ひたすらアップデート、更に何度か再起動…
電源すら入れていないのにセキュリティエッセンシャルがスキャン開始…
ゲンナリして使う気をなくしそのまま電源オフ…
をやったのが三ヶ月前、そして今回も…

このままでは永久ループだ!
必要になった時に即使えないモバイルなんてまったくの無意味。

Windows に文句を言ってもしかたがない。
とにかくアップデート時間の短縮と無意味スキャンをなくしたい。
ならば Linux にするしか無い、しかし Windows7 を消すのも躊躇する。

ということで Fedora 16 とのデュアルブートにすることにした。
ミニノートに Linux で無線 LAN とかは大丈夫だろうか、実験を兼ねて。

とりあえず Windows7 を起動して Linux を入れる空き領域の確保。
「スタートボタン」→「コンピューター」右クリして「管理」を選択。
「ディスクの管理」から C ドライブを選択、右クリして「ボリュームの縮小」
表示された最大値で圧縮、簡単に空き領域確保。

画像は Fedora を入れた後だから埋まっているけど右二つ分ほど領域が開いた。
後は Fedora Live CD を立ち上げ以前と同じようにインストールする。
Fedora 16 64bit Install (HDD) | PaePoi
Live 時に無線 LAN の指定をしておいたらそのまま引き継がれたよ。
デュアルブートにするにはインストール時に「空き領域に…」を選択。
だけで見事 GRUB でのブート選択ができる環境の完成。

Fedora 16 の起動時間は約 3 分…
Windows7 も安定するまではそのくらい掛かるけど、やっぱり遅すぎ。
起動後にバックでガリガリとかはまったく無いのは嬉しいけど。

当然のように最初から 1366×768 画面で起動。
GMA4500M のショボイグラフィックでも問題なく 3D デスクトップ。
ノートなのを認識して画面や電源の設定で節電項目が増える。
Windows の NTFS 領域にもマウントしてアクセスできる。
無線 LAN は選択して暗号化キーを打ち込むだけで接続完了。
Bluetooth マウスもアッサリ認識。
タッチパネルの指二本スクロールもマウス設定から指定可能。
天板を閉めると普通にサスペンド。

今の Linux って凄い、何の苦労もなくほぼ全自動だった。

そうそう音も普通に鳴る、昔は凄い苦労をした記憶があるが。
Intel グラフィックでも問題無い、以前は相性最悪だったのだが。
Compiz の Ubuntu だと解らないけど、GNOME 3 は Clutter なので。

動画再生支援は無いけど 1080p もギリギリ再生できる。
支援機能の利用はライセンス料がいるからしかたがないよ。

これでもうアップデートとスキャンでゲンナリすることは無い。
デスクトップと同じ OS だと 1.2GHz CPU の遅さを体感できるw

それにしても Linux は快適だ。
非アクティブのアプリでもホイールスクロールできるのが嬉しい。
たまに Windows7 を使うと「あれ?」ってなる、特に Explorer で。

ついでに Windows7 からもいらないアプリを削除。
Live 全削除、Adobe は Flash だけ残して削除。
RealPlayer Mini は配布が無くなっているって何よ、これも削除。
PDF は evince、メールは Opera、動画はノートで見ない。
よしスッキリ、でも次に Windows を使うのは又三ヶ月後くらいだろう。

realplayer

RealPlayer Mini テスト版
http://jp.real.com/?mode=rp_mini
というものがあるらしい、まさかココが軽量プレイヤーを作るとは。
Windows で動画をほとんど見ないけど(だってミニノートだもん)試してみる。

インストール直後にアップデートでこんなのが。
どう考えたって FFMPEG だよな、GStreamer と同じ感じになるかな。

ちょー!
一つ再生したらプレイリストに同一ディレクトリのファイルがリストアップ!
矢印キーはボリュームだ、まぁ我がアプリが特殊なだけなのだが。
自動リストアップ以外はよくあるプレイリストなのね、ふむふむ。

単独数値キーでリサイズ。
右にくっついているプレイリスト。
ウインドウ左上部クリックでメニュー。
Esc で終了できる。
気のせいだろうか、何か見覚えが…

一時停止は Space キーだし使い勝手も悪くない、シークも早い。
そのまんま FLV も H.264 も再生できた、私はこれだけで十分。
いくつかのキーボード操作に違和感があるけどカスタマイズ可能。
機能や設定項目も豊富、私はどうでもいいものばかりだけど。

画面上にマウスカーソルを置いても本家のようなウザい枠は出ない。
どういう心境の変化だよ、この会社らしいウザさがまったく無い。

それより何より。
いくらリサイズしても画面をはみ出さない、タスクバーに食い込まない。
Windows Media Player や VLC で一番困ることがまったくおこらない。
GNOME ならあたりまえなんですけどね、Windows ではアプリ側の仕事なので。

関連付けはコッチに変更することにした、とにかくサイズで困らないのがいい。
正式版でまた余計なことをやらなければ最強プレイヤーになりそう。
てか、個人製作プレイヤーはマジで終わった。

gdiplus save

Keyleigh をそろそろなんとかしたいと考えた。
拾ったデルヒャァコンポーネントを使っているだけのクソソフトだが。
せっかくなので画像コンバータ機能とかでも追加すれば面白くなるかも。

GDI+ を使うのが一番だよなぁ。
C# で使えば死ぬほど簡単だ。

using System.Drawing;
using System.Drawing.Imaging;
using System.IO;

namespace iconpoli2
{
	class Program
	{
		static void Main(string[] args)
		{
			foreach (var s in args)
			{
				string t = Path.ChangeExtension(s, "jpg");
				Bitmap b = new Bitmap(s);
				b.Save(t, ImageFormat.Jpeg);
			}
		}
	}
}

コンバートならマジでこれだけだ。
いや、せっかくなので C++ でやりたいぞ。
と思ったけど

Gdiplus::Bitmap * img = new Gdiplus::Bitmap(__wargv[i]);
img->Save(outname, &Gdiplus::ImageFormatJPEG);

とやっても全然上手くいかない。

Transforming a JPEG Image Without Loss of Information (Windows)
Retrieving the Class Identifier for an Encoder (Windows)

どうやら自力で CLSID を取ってくるしかないようで。
つか ImageCodecInfo って class なのにサイズを得て malloc なの?
試しに普通な new で作ったら見事にヒープ領域不足、どういう設計だよ。

とにかく MSDN の方法で上記と同じになるよう C++ で作ってみる。
C++ じゃ ChangeExtension なんて便利なものは無いし GDI+ 初期化も必須。

stdafx.h

#pragma once

// 面倒なのでココで参照追加
#pragma comment(lib, "gdiplus.lib")

#ifndef _WIN32_WINNT
#define _WIN32_WINNT 0x0600 // Vista
#endif

#include <stdio.h>
//#include <tchar.h>
#include <wchar.h>
#include <windows.h>
#include <gdiplus.h>

凄く無駄だと解っているけど tchar を利用しないで UNICODE 関数をまんま使う。
てか今となっては Ansi 関数を併用する必要は無いと思うんだが。
WCHAR や UINT のマクロも利用したくない。
だって Visual Studio は大文字マクロの型名では色が付かないんだよね。
というかなるべく小文字にしたいと思うのは多分 Python のやりすぎ。

iconpoli.cpp

#include "stdafx.h"

using namespace Gdiplus;

int GetEncoderClsid(const wchar_t* format, CLSID* pClsid)
{
	unsigned int  num = 0;
	unsigned int  size = 0;

	ImageCodecInfo * pImageCodecInfo = NULL;

	GetImageEncodersSize(&num, &size);
	if(size == 0)
		return -1;  // Failure

	// コレだとヒープ領域不足になる
	//ImageCodecInfo * pImageCodecInfo = new ImageCodecInfo();
	pImageCodecInfo = (ImageCodecInfo*)(malloc(size));
	if(pImageCodecInfo == NULL)
		return -1;  // Failure

	GetImageEncoders(num, size, pImageCodecInfo);

	for(unsigned int j = 0; j < num; ++j)
	{
		if( wcscmp(pImageCodecInfo[j].MimeType, format) == 0 )
		{
			*pClsid = pImageCodecInfo[j].Clsid;
			free(pImageCodecInfo);
			return j;  // Success
		}    
	}

	free(pImageCodecInfo);
	return -1;  // Failure
}

bool ChangeExtension(const wchar_t* src, wchar_t* dst, const wchar_t* ext)
{
	wchar_t path[4][256];
	_wsplitpath_s(src, path[0], 256, path[1], 256, path[2], 256, path[3], 256);
	_wmakepath_s(dst, 1024, path[0], path[1], path[2], ext);
	return TRUE;
}

int wmain(int argc, wchar_t* argv[])
{
	// GDI+ 初期化
	GdiplusStartupInput gdiplusStartupInput;
	ULONG_PTR gdiplusToken;
	GdiplusStartup(&gdiplusToken, &gdiplusStartupInput, NULL);

	for (int i=1; i < __argc; i++)
	{
		// makepath
		wchar_t outname[1024];
		ChangeExtension(__wargv[i], outname, L".jpg");

		Gdiplus::Bitmap * img = new Gdiplus::Bitmap(__wargv[i]);

		CLSID encoderClsid;
		int r = GetEncoderClsid(L"image/jpeg", &encoderClsid);
		if (r == -1)
		{
			wprintf(L"no CLSID");
			return 0;
		}
		// コレは上手くいかない
		//int result = img->Save(outname, &Gdiplus::ImageFormatJPEG);
		int result = img->Save(outname, &encoderClsid);
		if (result == Gdiplus::Ok)
			wprintf(L"Encode Success");
		else
			wprintf(L"Encode Failure");
		delete img;
	}
	// 後片付け
	Gdiplus::GdiplusShutdown(gdiplusToken);
	return 0;
}

長い。。。。。

たったこれだけのモンにえらく時間が掛かった、やっぱり C# のほうがいいかなと。
それと Python や C# ばかりやっていると開放処理をつい忘れそうになるよね。

template and generic

Fedora 15 待ちで Linux ネタが作れないのでしばらく .NET で。

.NET Tips ページもかなり整理が終わった。
UTF-8 INI 読み書き関連と STL/CLR はほとんど書き直し。
.NET Tips – L’Isola di Niente

C++/CLI を久々に使ってみて見つけた。

#include "stdafx.h"

using namespace System;

/* こっちだと演算子が使えないとエラーになる
generic <typename T>
T calc(T a, T b)
{
	return a + b;
}*/

template <class T>
T calc(T a, T b)
{
	return a + b;
}

int wmain(int argc, wchar_t* argv[])
{
	Console::WriteLine(calc(3, 7));
	Console::WriteLine(calc<double>(3.1, 7.3));
	Console::WriteLine(calc<String^>("私って", "ほんとバカ"));
	//=>10
	//=>10.4
	//=>私ってほんとバカ
	return 0;
}

template は generic へのマクロだと思っていたけど全然違う。
template キーワードなら C++ の STL と完全に同様なんだね。
使うかどうかは置いておいて。

せっかく C# の INI 読み書きクラスを作り直したんだから何かに使いたい。
SeeMe が現行 Opera で使えないのは知っているんだけどヤル気が出ない。
ヤルとしたらまったく違うインターフェイスに変更したいし、何か思いついたら。

PyGtk 関係は GTK3 が普通に使える GNOME3 Fedora に乗り換えが終わってから。
今整理したってあっというまに時代遅れになる、進化が早すぎるよ…

追記

今頃気がついたけどコレってもしかして C++ のテンプレート機能を呼んでいるだけ?
標準 C++ と何も違いが無いのだとしたら STL/CLR の存在価値って何なんだ。
知れば知るほど解らないコトが増えるのは標準 C++ と同じかよ…