【質問】ASP.NETスレ Part5【議論】

【質問】ASP.NETスレ Part5【議論】 at PHP

[前50を表示]
550:nobodyさん
09/07/06 19:43:38
>>548
少なくともユーザコントロールで、所有してるオブジェクトをそのままプロパティで公開するのは止めたほうがいいよ

551:nobodyさん
09/07/06 19:57:47
それは分かってるがID:/VP1pSJiが何をしたいか分からんことには。。

552:nobodyさん
09/07/06 20:16:06 /VP1pSJi
すいません>>545がちょっとまちがっていました
・user.ascx
protected sub name () as textbox
get
return txtname.clientID
end get
end sub

・main.aspx
dim TextName as textbox = name
TextName.text="Test"

つまりユーザーコントロールにあるコントロールをaspx側で操作したいというこです

553:nobodyさん
09/07/06 20:19:06
だからコントロールのプロパティをUserControlのプロパティとして公開しなさいっての

554:nobodyさん
09/07/06 20:21:29 /VP1pSJi
>>553
どうやるんですか？

555:nobodyさん
09/07/06 20:57:29
>>554
>>546-547

556:nobodyさん
09/07/06 22:05:11 Igs6oFx6
質問させてぇ～

「無効なポストバックまたはコールバック引数です。
イベントの検証は、構成の <pages enableEventValidation="true"/>、
またはページの <%@ Page EnableEventValidation="true" %> を使用して・・・」

っていう糞長いエラーが。。

状況はMultiViewの中のViewのなかのGridViewのなかに配置したTemplateField（ｲﾒｰｼﾞﾎﾞﾀﾝ）
に、
CommandName="delete"
OnClientClick="return confirm('削除してよろしいですか？');"

ってﾌﾟﾛﾊﾟﾃｨ設定をして、ゴミ箱のイメージボタンをおしたら削除されるようにしたわけ。

で、さらにこのGridViewのイベントハンドラを以下のようにしてるわけ。
OnRowCommand = "GridViewMeans_RowCommand"

で、このｲﾒｰｼﾞﾎﾞﾀﾝを雄と件のｴﾗｰが発生します。。。

そもそもこのｴﾗｰって何を意味するの？
「ぽすとばっくやコールバックのイベントが、それをレンダリングしたサーバコントロールから由来するとだめ」
しかもセキュリティの理由から？？
意味が分からない。
意味が分からないから対処方法も想像できない。単にenableEventValidation="false"にすればいいよ、とか
意味も分からず闇雲にトライエラーしたくないし。
だれか、ずばっと、こういうパラダイムがあるから、それを解決するためにこういうセキュリティ上の配慮が必要で、そのために
チェックしてるんだ！！！とか男らしい回答求む。

557:nobodyさん
09/07/06 22:24:58
>>556
URLﾘﾝｸ(techbank.jp)

558:nobodyさん
09/07/06 22:53:47
>>557
ご回答ありがとうございます。
するってぇと、何でImageButtonをViewStateに保存しちゃまずいんですかね？
そういうモノだから？？

559:nobodyさん
09/07/06 22:56:34
とりあえず試してみました。
変わりませんでした。。
やはりあの、、原理を。。

560:nobodyさん
09/07/06 23:10:21
例えばRepeaterやGridViewコントロールなどのように、
動的に行が生成されるコントロールで、
さらに動的にRepeaterやGridViewなどのような動的に行を生成するコントロールを作成し、
その中でClickイベントを実装すると、その問題が発生するということだったはず。

ページによって存在するかどうかわからないイベントの発生元が存在した場合に、
それを検証する術がないのでエラーになるという感じだったような気がする。
例えばRepeaterの中のLiteralコントロールに、サニタイズをせずに文字列を表示させてしまい、
擬似的にポストバックされるコードを記述されてしまうのを検知するのと区別が付かないとかなんとか。

記事のありかは忘れた。

561:nobodyさん
09/07/06 23:23:44
>>560
おお～。なるほど！ありがとうございます
分かりません！

でも自分の頭じゃ理解できないってことだけは分かりました。

まぁMFCなんかでもダイアログボックスを表示中に他のタイマーとかのイベントがくると
ダイアログボックスのなかのメッセージポンプがそれを処理しちゃって、
その辺を考えて作らないといけないとか、そんな苦労を思い出します。
要は凝ったフレームワークにありがちな落とし穴って事ですかね。

うーん。困ったｗ

562:nobodyさん
09/07/06 23:35:38
>>554
・main.aspx
dim TextName as textbox = CType(ユーザコントロールのID.FindControl("txtName"), TextBox)

これでお前のやりたいことはたぶんできるだろう

これをやるべきじゃないとか何とかいろいろあるんだが、
まあそれは勉強してくれと言うしかない

563:561
09/07/07 00:48:14
いろいろ試行錯誤した結果、TemplateFieldのItemTemplateの中身がLinkButtonだと削除機能は全く問題ないけど、
ImageButtonだとだめみたいです。
ImageButtonにしてEnableViewStateをFALSEにしてもだめみたいです。
なんか、ImageButtonがだめのかねぇ。
もう寝ます。

564:561
09/07/07 21:59:56
海外のサイトあさって回答を見つけたよ。
なんでもGridViewのサーバーサイドのイベントが2回以上起こると発生するらしい。
自分の場合は最初に（書いてなかったけど）RowCreateイベントを使ってる。
そして2回目はボタンをクリックしたときに発生する。
この２回のポストバックにおいて、RowがもってるID（つまりe.Row.ID）が食い違っていると
この検証に引っかかるらしい。
（ただのMSのバグじゃねーの？？）
自分の場合、最初はRowCreateで、この時点ではe.Row.IDはNULL、たぶんボタンをクリックしたときはなんか値が入ってるんだろうね。
それが食い違っているからだめ～ってこと。
なんで最初にユニークな値を突っ込んでおけばいいらしい。
つまり
RowCreate()
{
e.Row.ID=Guid.NewGuid().ToString();
}

これでOKだった。でもなぜLinkボタンならよいのかは不明。Linkボタンはポストバックじゃないからかな。

565:nobodyさん
09/07/07 22:06:15
1ページに対してイベントは1回だから別に間違ってないだろ
それこそ、故意にイベントを発生するタグを挿入される危険性を排除するのが目的なんだから

566:nobodyさん
09/07/07 22:10:13
なんだ、兄さんよく知ってる感じだな。
もっと早く出てきて教えてくれよ。

567:nobodyさん
09/07/07 22:27:17
IDが変わるような操作したあと、databindし直すのが正しい操作じゃないのか？

568:nobodyさん
09/07/07 22:58:50
>>567
たぶんあなたの言っていることは正しい。

569:nobodyさん
09/07/07 23:52:10
javascriptどうすれば簡単に覚えられますか？
VBに浸りすぎてぜんぜんわからん

570:nobodyさん
09/07/07 23:57:57 ID58Jon/
.NETではなくASPなのですが、スレがないのでこちらに書き込みます。
DBテーブル上にBASE64エンコードされた画像データ（テキスト）が格納されています。
これをデコードしてresponseで出力したいのですが。。

エンコードはBASP21のBASE64関数を使い、ファイル経由で行いました。
デコードはファイル経由にしたくないので、なんとか直接出力したいのですが。
ちなみにBASP21でデコードすると

Dim o_buf
o_buf = objBASP.BASE64(rsRecord.Fields("Field_name").value, 1)
Response.BinaryWrite o_buf
Response.End

のような感じになりますが、o_bufにバイナリイメージの先頭数byteしか入ってこなかったので、
BASP21は使えないと考えています。
「これぞ王道」のような方法があればお教えください。
いまさらながらASPでプログラムを作成する案件がでてきて、慣れない中苦戦しているもので。。
よろしくお願いします。

571:nobodyさん
09/07/08 00:10:09
>>570
>エンコードはBASP21のBASE64関数を使い、ファイル経由で行いました。
直接デコードしたら表示できる？

>デコードはファイル経由にしたくないので、なんとか直接出力したいのですが。
ファイル経由にしたらデコードできる？

>o_bufにバイナリイメージの先頭数byteしか入ってこなかったので
なんで入ってこないの？

>「これぞ王道」のような方法があればお教えください。
バイナリのままデータベースに保存できないの？

572:nobodyさん
09/07/08 00:19:39
>>569
VBを窓から投げ捨てる

573:nobodyさん
09/07/08 01:35:13 ZNTcUj46
レスありがとうございました。

>>エンコードはBASP21のBASE64関数を使い、ファイル経由で行いました。
>直接デコードしたら表示できる？

>>デコードはファイル経由にしたくないので、なんとか直接出力したいのですが。
>ファイル経由にしたらデコードできる？

　ファイル経由でのデコードはできています。（BASP21利用で）
　このファイルをビューアで見ることもできます。
　サーバ負荷が高くなりそうなので、ファイル経由は避けたいと思っています。

>o_bufにバイナリイメージの先頭数byteしか入ってこなかったので
なんで入ってこないの？

　BASP21の関数利用の結果がそうなっていました。
　ここは理由はよくわかりません。。

>「これぞ王道」のような方法があればお教えください。
バイナリのままデータベースに保存できないの？

　バイナリのまま保存する方法も現在調査中です。
　エンコードする方法と、両方を調べている最中です。

　どうぞよろしくお願いします。

574:nobodyさん
09/07/08 09:09:29
>>573
モード6と7が対なのはわかるんだけど、
それと、その他のモードに互換性があるのかな
他のは、いわゆるwidestringだけに対応してて、バイナリには対応してないんじゃないのかな。
異なるモード間で互換性がないと意味がないから、
ファイルをエンコードするのに、FSOでファイルを読み込んで、
一度変数に入れてから6と7以外のモードで変換してみたらできるのかな？

575:nobodyさん
09/07/08 18:32:48
aspの質問ですらなく、BASP21の話じゃないか、それ
BASP21って専用のスレとかないのか？
それか、サポート付きの有償版みたいなのなかったか？

BASE64ってそんなに難しい規格じゃないから、
自分でデコードする関数書いたらどうだね

576:nobodyさん
09/07/09 00:56:21
このスレ的には、
FCL使えって感じだけどな

577:nobodyさん
09/07/09 17:08:52
Framework Class LibraryってClassicASPにも存在するの？

578:nobodyさん
09/07/09 22:37:40
ﾍﾟｰｼﾞの名前変えたらものすごい変なｴﾗｰが出るようになった。。

579:nobodyさん
09/07/09 22:59:29
ASP.NETは一つ一つのページがpertialクラスになってて、
ページ名がクラス名になってるんだけど、
リネームしてもそのクラス名は変更されないから
リネームしたことでページ名が重複しちゃったんじゃね？

580:nobodyさん
09/07/09 23:02:18
>>579
まぁ変え方がまずかったんだと思う。いま一生懸命直してます。

581:nobodyさん
09/07/09 23:11:57
1日1回はローカルでもいいから、別のトコにバックアップとったほうがいいよ
データベースがらみとか、アドオンの帳票がらみでわけわからん具合になること結構あるから

582:nobodyさん
09/07/11 14:43:11
よくも悪くもバッドノウハウの固まり

583:nobodyさん
09/07/13 00:21:32
画面上に100個位コントロール（TextBox）が並んでて、Postされた時に一々値を拾うのが
めんどくさいんですが。なんか上手い方法無いですかね？
特に、Repeaterで自動生成されたTextBoxとか、IDもサーバで勝手に振られるのでどうして
いいのか分かりません。

やりたいこと：Postされた値をなんか上手い方法でDataSetに入れてしまいたい。
DataBindって参照しか出来ないEvalじゃなくて、双方向更新も可能なメッソドもあるとか？

584:nobodyさん
09/07/13 01:18:02
>>583
具体的には忘れたけど、こんな感じ

■Repeaterの場合
for (int i = 0; i < this.Repeater1.Items.Count; i++)
{
　RepeaterItem ri1 = this.Repeater1.Items[i];
　TextBox textBox = (TextBox)ri1.FindControl("textBox");
}

■ページにポトペタした場合
Control control = this.Page.FindControl("controlName");
でID名でコントロールが取得できるので、連番で名付けてループさせて取得すればいい

DataSetに格納したい行をClassか、structで宣言して、
ループする度にインスタンスを生成し、IList<T>に格納していけばいい。
別途IList<T>からデータを取得してDataSetに格納するクラスを別途作成す。。

585:nobodyさん
09/07/13 02:12:46
>>583
>DataBindって参照しか出来ないEvalじゃなくて、双方向更新も可能なメッソドもあるとか？
使い勝手があれだから、きっと絶対必ず役に立たんがBindというのはある。
例えばObjectDataSourceのConflictDetectionを設定してやれば、
UPDATEやDELETEで指定したメソッドに対して、
変更後の値と変更前の値を自動で放り投げてくれる。

586:nobodyさん
09/07/13 16:29:19
VS2005 + IIS6.0 + IE6.0 or 7.0で開発しております。
DataGrid(GridViewではありません)のヘッダー固定に関しての質問です。

DataGridのヘッダー行を固定しようと思い、ネット上でサンプルを参考にして
浮いているように見えるのですが、とりあえずヘッダー行の固定を実装しました。
参考URL：URLﾘﾝｸ(jsajax.com)

ですが、この固定しているヘッダー行が常に最前列に出ているようで
画面上のメニューバーから展開されるサブメニュー項目が、ヘッダーの後ろに表示されてしまいます。
メニューバーはJQueryで作成しています。
参考URL：URLﾘﾝｸ(css-tricks.com)

JQueryで作成している箇所は、DBから動的に項目を取得して
メニュー自体をHTMLで作成しているので、JQueryをはずすことはできません。

ヘッダー行かメニュー項目のZ-INDEXで解決するかと思ったのですが、
どうも効いてないようで解決方法の糸口が見つかりません。
どなたか詳しい方いらっしゃいませんでしょうか？

587:nobodyさん
09/07/13 16:53:47
jquery.dropdownPlain.jsでz-index記述してみたら

588:nobodyさん
09/07/13 18:05:58
>>587
やってみましたが結果は変わらずでした

固定しているヘッダー行が浮いたような状態になり、
DataGridよりも若干右にズレているのも気になります。
これが問題なんでしょうか・・

589:nobodyさん
09/07/13 18:25:38
メニューを表示させなければうまくいくのか？
あと改行してメニューが干渉しない位置にヘッダーを表示させて場合はうまくいくのか？

うまくいくのならメニューを表示させたことで、メニューのスタイルシートが、
ヘッダのスタイルシートに悪影響を及ぼしてるんだろうから、
メニューの何が悪さをしてるのか、一つ一つスタイルを削って試して見るしかない

590:nobodyさん
09/07/14 21:55:30 s5DuVBkc
VS2008、C#でASP.netという構成ですが・・・すいません、ビルドの後、プリコンパイルされたDLLというのは何処に格納されるのでしょうか？
ASP.net 2.0の、しかもCodeBehind属性を使っているレガシーなアプリをメンテナンスしているのですが、CodeBehindに指定されている.csの内容を修正してもそれが反映されません。
（aspxの内容を修正した場合は反映されています）

ビルドしてプリコンパイルすればいいかと思ったのですが、ビルドしても\binに格納されているDLLが更新されないのです。
おそらくどこかに設定があると思うのですが、見つけることが出来ませんでした。
よろしければアドバイスをお願いします。

ちなみに、Webサイトのプロパティの「MSBuildオプション」→「出力フォルダ」は、修正してみましたが特に変化はありませんでした。

591:nobodyさん
09/07/14 22:00:55
プロジェクトフォルダ-releaseフォルダの中かな
もしくはdebugフォルダ

592:590
09/07/14 22:44:54
>>591
早速のお返事、ありがとうございます。
が・・・ありませんねぇ、どちらも。
もしかしてプリコンパイルは関係ないのかな？　でも、今参照しているbinの中のdll、参照外すと動かなくなるしなぁ・・・。

593:nobodyさん
09/07/15 01:38:50
VS2008のASP.NET2.0ということは、Webアプリでなく、Webサイトだと思うけど、
参照設定で、他のDLLを参照する設定になってない？
普通、通常に使用しているだけなら、Webサイトで作成していてbin以下にdllが
作られることはないと思う。
だからビルドしても、外部参照のdllは更新されるはずがないような気がする。

webアプリだったら、あまり詳しくしらないのでよくわからん。

594:nobodyさん
09/07/15 05:36:31
CodeBehindならWEBアプリな予感
だったらビルドしたらbinディレクトリにあるはずだが

WEBサイトならビルドしてもDLLは（見えるところには）作成されない
プリコンパイルってVSからできたっけ？

というか、参照してるDLLってなんのこと言ってるんだ？
そのプロジェクト以外のDLLをBinに入れて参照してるなら、
そんなもんはそのプロジェクトいくらビルドしても変わるわけないぞ

595:nobodyさん
09/07/15 05:56:10
>>594
IDEからプリコンパイルできると書いてあるね
URLﾘﾝｸ(msdn.microsoft.com)

Webサイトでもコードビハインドだし、
「プリ」ってわざわざ付けるということは、webサイトなんじゃないかと思うんだけど。

596:nobodyさん
09/07/15 11:45:02
エスパー解答

実はプリコンパイルは関係なくて、
>CodeBehindに指定されている.csの内容を修正してもそれが反映されません。
>（aspxの内容を修正した場合は反映されています）
のあたりを詳しく聞く必要があるとみた！

.csの内容を修正しても反映されないって、例えば画面の初期化処理だとか、
ポストバック時の処理を変えたりしてみても以前のロジックが走る、
ってことかな？

.csを削除してみるだとか、新しいページ追加して確認してみるとかはどうでしょう？

プリコンパイルとかWebサイトとかの話はよく分からないので、分かる方お願いします。

597:590
09/07/15 11:55:15
>>593-595

失礼、「Webサイト」でしたね。が・・・。

>WEBサイトならビルドしてもDLLは（見えるところには）作成されない
あれ？　もらってきたソース一式に、\binディレクトリがありますけど・・・？

えっと、binにアプリケーション名.dllを放り込むと、VSの方で勝手にそのdllへの参照設定をします。
その参照設定を外すとdllが削除され、「型 '（アプリケーション名）.Global'が読み込めませんでした」ってコンパイルすら通らなくなります。
（当然、「デバッグ」→「デバッグ開始」でも動きません）
それで、「ああ、ビルドしてdllを作り直せば、.csへの修正が反映されるのね」と思ったのですが、
「ビルド」→「Webサイトのビルド」ではDLLが作られない／更新されない・・・おや？　というところで詰まっているのです。
うーん・・・別に、開発してるときはプリコンパイルなんてしてくれないくていいのになぁ。

598:590
09/07/15 11:57:39
>>596
おっと、すれ違い失礼。ええ、問題になっているところはソコですね。
ただ、>>597のような考えで「プリコンパイルされたDLLが更新されないのが問題だよね？」と思ったのですよ。
ちょっとやってみましょう＞新しいページを追加

599:590
09/07/15 12:23:54
>>598
ダメですね。「型'アプリケーション名.hogehoge'を読み込めません」となります。
.csを無視してDLLを見に行ってるような感じです。

600:590
09/07/15 19:32:14
お騒がせしました。
結局、.net 2.0を明示的に指定して最初からソリューションを作り直し、そこにソースをコピーして再ビルドをかけました。
何が悪かったんだろう・・・。
※ツリー部にドラッグ＆ドロップでコピー可能、しかも関連ファイルまで根こそぎ持っていくのにはちょっと感心しました＞VS2008

とりあえず.csの修正は反映されるようになりましたが、やはりリビルドはしないとダメですね。

601:nobodyさん
09/07/15 19:37:54
>>600
ソースファイルのタイムスタンプがおかしくなってるとか、マシンの時刻がおかしくなっているとか
プロジェクトの何かのファイルのタイムスタンプがおかしくなっているとか…。

602:nobodyさん
09/07/15 19:55:28

たぶん、webアプリケーションと間違えてないか？

それか一つのソリューションに、webサイトプロジェクトと、他のプロジェクトがあって、
webサイトプロジェクトから、他のプロジェクトへの参照設定がされてる。
dllは、他のプロジェクトで作成したクラスのdllだからASP.NETの.csを変更してビルドしても
何の変化もないので不思議がってる。

こんなところだろ

603:nobodyさん
09/07/16 01:59:14
現在Visual Studio 2008(VB.net)を使用しMasterPageの中に
<div></div>ブロックで囲んだGridViewを配置し、
ヘッダー行を固定しようと、.Freezingのお決まりのCSSを書き
GrdiViewHeaderのCSSにそのFeeezingのCSSを指定したところ、

ヘッダー行は正常に固定する事が出来たのですが、
<div>ブロックで正常に width:450pxと指定しているにも関わらずGridViewのヘッダー行(だけ)が
その<div>ブロックの幅を右横に突き抜けて表示されてしまいます。
一体何が原因なのでしょうか？
※IE７

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
指名　｜　　年齢　｜　趣味　｜　経験年数　｜　

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
　A　　　　　15　　　｜｜　↑ヘッダー部分だけが突き抜けてしまう。(ここで趣味・経験年数)
　B　　　　　15　　　｜｜
　C　　　　　15　　　｜｜
～～～～～～～～～
～～～～～～～～～｜

604:nobodyさん
09/07/16 03:01:51
スタイルシートはdivで指定しても、その内側のタグのスタイルの指定で
表現してくれないことがあるから、そのヘッダー行に直接スタイルを適用してみたら？

というか、そういう時は、生成されたhtmlのソースをローカルなどにコピペしてブラウザで表示させるなどして、
関係ないhtmlタグを次々と消していって、目的とするタグだけで確認したほうがいいよ。
まったく関係無いと思われるスタイルが影響している場合があるから。

その目的とする表示を構成しているタグだけを残して他のタグをすべて消去し、
それでも問題が発生するかどうか確認するなどして、
他の要素が影響を及ぼしてる可能性をなるべく排除すべき。

605:nobodyさん
09/07/16 03:18:17
>>604
ありがとうございます。
今日会社で試してみます。

606:nobodyさん
09/07/16 09:29:33
>>600
レガシーなって、もともとはどのバージョンで作ってあったんだ？
それはWEBアプリで作ってあったのか、WEBサイトでつくってあったのか？

>>602
俺がエスパーするに、元がWEBアプリだったのを、今はWEBサイトで修正しようとしてる
今修正した部分はWEBサイトなんで、アプリケーション.DLLに反映されない
既存部分はWEBアプリなんで、アプリケーション.DLLへの参照がないと動かない

ソース全部コピーしたってことは、今全部WEBサイトになったんで動いてる

ま、こんなとこだろう

607:590
09/07/16 16:43:13
>>606
そうですね。*.slnファイルも貰ったのでそのまま開いたのですが、こちらで空のwebサイト、webアプリを作成して比較してみると、webサイトの*.slnのようです。
これで開発してる、って言ってたんだけどなぁ・・・。

608:nobodyさん
09/07/16 19:05:01
>>606
その可能性が高そうだね
つかwebアプリをwebサイトに移植しても、そのままで動作するんだな

609:nobodyさん
09/07/16 22:19:36
VS2005は知らんが、VS2008でWebサイトを作成してビルドすると
勝手にbinフォルダが作成されてる。その中にaspxに付随する.csやAPP_CODE配下のクラスファイルが
コンパイルされたdllが放り込まれる。aspxのヘッダはこのbinフォルダのdllを見に行くように全て書き換えられる。

別にビルドしなくても、.csのソース付きaspxをWebサーバに配置しても
IISとASP.NETは普通に解釈してくれる（まぁビルドするのと同じことしてるんだろけど）
正式リリース時は速度&セキュリティを考えてビルド方式にしたほうがいいよな。。

610:nobodyさん
09/07/16 22:25:32
VS2008のWebサイトで、ビルドしても、リビルドしても、binフォルダもできないし、dllもできないぞ？

611:nobodyさん
09/07/16 23:25:29
>>609
お前の言うWebサイトとは、VSでのプロジェクトの種類としてのWebサイトか？
一般的な意味でのWebサイトか？

一般的な意味でのWebサイトやWebアプリって言葉と
VSでプロジェクトの種類としてのWebサイトとWebアプリってのは別の話だぞ

binフォルダにDLL作るのはWebアプリだ。ソース修正したらビルドしないとDLLに反映されない
WebサイトではDLLは通常見えるところには作られてない。ソース修正したら自動的にコンパイルされ反映される
これを任意のタイミングで指定したところにDLL作らせるのがプリコンパイル

実際のところはWebアプリかWebサイトかは、VSが.ASPXのページディレクティブをどうするかだけで
ASP.NETは各ページの指定通りに動く。なので混在してても動く

612:nobodyさん
09/07/16 23:35:34
>>610
悪かった。ビルド→Webサイトの発行でやってみてくれ

>>611
VSのプロジェクトのWebサイトですよ

613:nobodyさん
09/07/17 00:38:13
それは発行するとプリコンパイルされるだけの話

614:nobodyさん
09/07/17 00:40:18
それぞれのメリット

・Web サイトの発行ユーティリティを使用する利点
プリコンパイルプロセスにより、コンパイル時エラー、および Web.config ファイルと他の非コードファイル内の潜在的なエラーを検出できます。
ソースコードは、.aspx ファイル内のマークアップを含め、Web サイトから削除されます。
これにより、知的財産を保護でき、第三者がサイトのソースコードにアクセスしにくい状況を作ることができます。
サイト内のページが既にコンパイルされているため、最初の要求時にページを動的にコンパイルする必要がありません。
これにより、ページの初期応答時間を短縮できます。ただし、ページが動的にコンパイルされる場合でも、以降の要求についてはその出力はキャッシュされます。

・Web サイトの発行ユーティリティを使用する欠点
指定する発行オプションによっては、サイトを変更する際、再コンパイルが必要になる場合があります。
したがって、サイトの開発中、頻繁に変更を加えるような場合にWeb サイトの発行ユーティリティを使用することは実用的ではありません。
Web サイトの発行ユーティリティでは、コンパイル済みサイトをリモートサーバーに配置することはできません。
ローカルコンピュータまたはローカルエリアネットワーク上の別のコンピュータにのみコピーできます。

615:nobodyさん
09/07/17 01:10:21
>>614
それはMSのコメントなのか？

＞Web サイトの発行ユーティリティでは、コンパイル済みサイトをリモートサーバーに配置することはできません。
発行ユーティリティでFTP経由を指定できるんだが、これはリモートサーバとはいわないのか

616:nobodyさん
09/07/17 01:15:08
すまんVWDの話な

617:nobodyさん
09/07/17 01:30:49
説明がめんどいからURLだけ
URLﾘﾝｸ(msdn.microsoft.com)

VWDじゃなくても、発行ユーティリティを使用した欠点に、
>Web サイトの発行ユーティリティでは、コンパイル済みサイトをリモートサーバーに配置することはできません。
>ローカルコンピュータまたはローカルエリアネットワーク上の別のコンピュータにのみコピーできます。
の記述はあるな

FTPの利用は、Webサイトのコピーツールのほうらしいなぁ

618:nobodyさん
09/07/19 17:06:01
「検索」ﾎﾞﾀﾝを押されたときにSQLを実行して実行結果をGridViewに描画させたいです。
SQLは、ﾕｰｻﾞが指定した検索条件でいろいろ動的に変えたいので
SqlDataSourceのSelectCommandでは対処できないのかな？と思ってます。

そこで、「検索」ボタン押下されたときにポストバック処理の流れで
GridViewのDataSouceにArrayとかそんなようなオブジェクトを渡して描画させたいです。
そんなようなやり方でいいんですかね？

619:nobodyさん
09/07/19 19:03:15
>>618
基本的にはそれでいいが、SQL Injectionには気をつけろ

620:nobodyさん
09/07/19 19:04:33
ありがとん

621:nobodyさん
09/07/19 19:30:24
単に検索条件変えるだけでSQL文の構造が変わる訳じゃないのなあら
SqlCommand の Parameter 使うとか。

622:nobodyさん
09/07/19 23:37:25
面倒かもしれないけど、自前のクエリ実装と、Repeaterの組み合わせのほうがいいと思うんだけどなぁ

623:nobodyさん
09/07/20 01:35:00
>>622
そんなんわかるほどスキルないもん。
ヒントだけでもいいから教えてください。

624:nobodyさん
09/07/20 16:03:44
>>623
プロジェクトのデータセットを追加して、GridViewにBindするだけ
何かを選択させて条件で表示させたいなら、DataTable.Select("Query")を利用すればいい

625:nobodyさん
09/07/20 16:45:16
>>624
ありがとうございます。
キーワードが増えたのでそれで勉強してみます

626:nobodyさん
09/07/20 23:36:16
>>624
SqlDataSourceなりObjectDataSourceなり
データソースを使わせた方がいいと思うが…。
ページングができませんだの、編集ボタンでエラーが出ますだの言われかねんぞ。

627:nobodyさん
09/07/21 13:52:20
ASP.NETのプロジェクトを作成して、そのなかでSQL ServerのDBに対して「ADO.NET Entities Data Model」
LINQでアクセスしています。

このDBを定期的に掃除するコードを実行したいので、タスクスケジューラから実行できる、
コンソールアプリのプロジェクトを作成しました。このプロジェクトから、↑のASP.NETのプロジェクトを
プロジェクト参照した場合、

new XXXXDatabaseEntities()

のところで、TypeInitializationExceptionが発生します。

ASP.NET側のプロジェクトのWeb.Configにあった接続文字列をこのコンソールアプリのプロジェクトの
App.Configにコピペしてきたのですが、それでは不十分なのでしょうか？

628:nobodyさん
09/07/21 17:13:29
>>627
いま気づいたが、ひょっとしてDLL側にconfigを用意してそこに接続文字列を書かないといけないのか・・。

629:627
09/07/21 18:40:41
解決しました。

・DllのConfigは書いても無駄
・App.Configの内容がXXX.exe.configにビルド時にコピーされる

この2つを理解していなかったのが原因でした。

630:nobodyさん
09/07/21 19:36:42
>このDBを定期的に掃除するコードを実行したいので、タスクスケジューラから実行できる、
>コンソールアプリのプロジェクトを作成しました。
ストアドプロシージャで作成してSQLのjobから実行したほうがいいんでないの？

631:627
09/07/21 20:01:58
>>630
ストアドプロシージャは書くのが面倒＆書き慣れていないので、LINQで書きたいのです。

また、ログをDBに出力するメソッドなどは既に用意してあるので、
出来ればそのメソッドを用いて、DBの掃除をしたときにログを出力したいのです。

ところで、SQLのjobなら定期的に実行する仕組みがIISかSQL Serverかに搭載されているのですか？

632:nobodyさん
09/07/21 20:30:30
うろ覚えですまん
MSSQLには定期実行するjobの機能がある。ただしExpress以上。
jobがなくても、SQLCMDだったかなで、別途ファイルに保存したクエリを実行できるから、
これをOSのタスクスケジューラーで実行するという方法もあったはず

ストアドプロシージャでも、SQL/CLRを使えば、.NETが使えるから、
Linq To Entitiesも、ログを残すこともできるんでないかな。
.NET3.5でSQL/CLR使ったことないからよくわからん。

633:627
09/07/21 20:44:49
>>632
ああ、SQL Serverにジョブを定期実行する仕組みがあるのですね…。
これは知りませんでした。勉強になりました。

634:nobodyさん
09/07/23 06:02:37
>>631
自分はストアド派だなぁ

その「DBの掃除」がストアド化されていて
後で「ログを出力」という要件が追加になった場合、
ストアドの中だけ弄れば済む。

「後で要件追加(変更)」なんて設計者としては最初から織り込まないといけないと思う。
→ストアド内でログ出力するロジックを追加した方が総工数は下がる

635:627
09/07/23 13:07:42
>>634
> →ストアド内でログ出力するロジックを追加した方が総工数は下がる

それはストアドを駆使して書いてある場合の話であって、ASP.NETでの開発の場合、
ストアド使わずにLINQで殴り書きするほうがインテリセンスも使えて生産性が高いように思うのだが。

636:nobodyさん
09/07/23 14:04:17
つSQL CLR

637:627
09/07/23 14:25:10
>>636
SQL CLRは技術的に見ても面白いテクノロジーですが、
LINQに比べると書きやすさがずいぶん劣るように思います。

638:nobodyさん
09/07/23 15:01:03
コーディングのし易さ、早さ、書きやすさを最大限に追求することで、
プロジェクト全体の保守を含めた生産性の高さが最大になる案件やシステムなら、
そうすればいいじゃんとしか言えない。

639:627
09/07/23 15:36:04
>>638
ああ、ええ、まあ、そうですよね・・。

もう少し生産的な話として・・

LINQで書いたものはCLRに変換されてserver sideで実行されるのですから、
ストアドプロシージャがLINQで書ければ便利な気がするのですが、どうでしょう？

640:nobodyさん
09/07/23 15:42:28
データベーステクノロジの使い分けとかみたいなのが
赤間さんとかの対談の形で
MSDN のページに載ってたんだけど
今探したら見あたらないな

641:627
09/07/23 15:49:30
>>640
これのことですかね？
URLﾘﾝｸ(msdn.microsoft.com)

642:nobodyさん
09/07/23 16:03:33
そうそう、それそれ。

643:nobodyさん
09/07/23 16:11:21
分業が必要な規模のアプリの場合、
その複数のプログラマがみんな美しいSQL文を書けるわけじゃないし
マニュアル等々で均一化するのも大変

1人のデータベーススペシャリストに
美しいSQL文でストアド作らせてた方が効率いいだろ、と感じる

あと、ASPの場合、外部からのハックキングを想定せねばならず
データベースへのアクセス権限としてテーブルへの直アクセスを許したくない

644:nobodyさん
09/07/23 16:15:12
仕様変更でDBのフィールドが一つ増えるたびに、
関係するクライアントアプリやASP.NETに記述したlinqをすべて書き直すなら、それでもいいんじゃね？

単一クエリなら問題ないが、1行の操作が他のテーブルに影響を与えるなら、
ストアドプロシージャやビューをフルに活用したほうが、
処理をDB内にカプセル化できるから、仕様が変更されても、
アプリケーションを変更する必要がないし他でも簡単に使いまわすことができる。

その典型例がDBを掃除するコード。
引数が必要ないからアプリ側に影響を与えないし、
ループして複数の行に対して処理するだろうからストアドのほうが高速だし、
トランザクションも明示的に処理ができる。

645:nobodyさん
09/07/23 16:16:25
一つのページで大量のクエリかけなきゃいけないときってどうしてるの？
select * from a;
select * from b;
...

って感じでやって取り込むのがいいの？

646:627
09/07/23 16:25:09
>>643-644
> 仕様変更でDBのフィールドが一つ増えるたびに、
> 関係するクライアントアプリやASP.NETに記述したlinqをすべて書き直すなら、それでもいいんじゃね？

これについてですが、私の場合、DBにアクセスするコードは、サブのプロジェクトを作ってそこに集約させてあるので、
DBのフィールド1つごとに修正する箇所があちらこちらに発生するということはないです。

ただ、ストアドで処理をDB内にカプセル化するという発想やDBのスペシャリストにストアドを書かせるという発想は
私にはなかったので643,644は本当に参考になりました。ありがとうございます。

647:nobodyさん
09/07/23 16:31:51
>>645
取得したいデータによって、動的に取得したいテーブルが変化するとかへんな設計してなければ、
二つのテーブルから合計値を取得するとか、簡単なものなら
クラスにクエリをたくさん記述して、各ページで再利用してる場合もある

ただ、複雑な計算が必要だったり、テーブル数が多くなる場合には、
MSSQL側に、その計算式をまるごとビューとして登録するか、
テーブル値関数として登録してる。

プログラム側では、一つの表として取得できるのでそれを描画するだけ。

648:nobodyさん
09/07/23 16:36:22 FURNmJTN
VS2005(VB)で開発しています
ドロップダウンリストを使用してデータを格納しているのですが
画面上からドロップダウンリストを操作した時に、表示される項目の向きが
常に下方向のみ表示できる方法はないでしょうか？
＿＿＿＿＿＿＿＿
[＿＿＿＿＿＿＿]▼
項目A
項目B
項目C

このように表示したいのですが・・・。
現状だと▼ボタンを押して表示されるデータが、リストボックスの中央から
表示されているような状況です

宜しくお願い致します

649:nobodyさん
09/07/23 16:36:55
>>646
それだと、仮にクライアントアプリだと、修正されるたびに、すべてのPCにデプロイする必要があるから面倒

DBの掃除コードはコンソールアプリからだけの実行かもしれないが、
仮にコンソールアプリからでもASP.NETからでも利用したい機能が発生した場合、
一つのプロジェクト内のクラスが変更になれば、両方をデプロイなり発行しなくちゃいけない。

DBに登録すれば、それに関するストアドの修正だけで済むので、
クライアントもASP.NETもコードを変更する必要がないので。

650:627
09/07/23 17:04:52
>>649
ああ、なるほど。クライアントアプリのときはそうでしょうね。

651:nobodyさん
09/07/23 17:10:18
あんまりストアドに頼ると、DBMSを変更しづらくなるのがやだなあ。
よほどの理由がない限り、DBMSへの機能依存を前提とした設計は
避けたほうが無難じゃね？

652:nobodyさん
09/07/23 17:18:22
>>650
コンソールとASPでやってて、SQLを別プロジェクトにしてる時点で、
同じDLLをASPとコンソールの二つからみてるわけだから同じじゃん
異なるバージョンのDLLで稼働してるのが気持ち悪くない人なら別にいいけど。

>>651
DBそのものの変更の可能性を考えるのなら、
使用言語が変更しづらくなる可能性も考慮しなきゃｗ
ストアドなら、そこにアクセスして操作できる言語なら
言語に依存せずに利用することができるとも言えるｗ

653:627
09/07/23 17:25:10
>>652
> 同じDLLをASPとコンソールの二つからみてるわけだから同じじゃん

サーバーサイドだけならdeployする手間が、普通のクライアントアプリとは違うので
>>649の「それだと、仮にクライアントアプリだと、修正されるたびに、すべてのPCにデプロイする必要があるから面倒」
という問題は無いかな、と思いました。

> 異なるバージョンのDLLで稼働してるのが気持ち悪くない人なら別にいいけど。

この部分がいまひとつ理解できていないのですが、私の構成は次のようになっています。

コンソールプロジェクト = DBの掃除を行なうコードを書いたプロジェクト(A) + DBへアクセスするためのサブプロジェクト(B)
ASP.NETのプロジェクト = 普通のASP.NETのプロジェクト(C) + DBへアクセスするためのサブプロジェクト(D)

上の B = D で、これはどちらも同じバージョンのDLLなのですが・・。

654:nobodyさん
09/07/23 17:34:37
>>653
別に、あなたのやり方を否定してるわけでも、自分のやり方を推奨してるわけじゃなくて、
相反する考え方があるという事なんで、あくまで一般論の話ね。

どんな想定かわからないけど、複数のものを変更しなくちゃいけない場合、
その時点で変更し忘れ等のミスが発生する可能性が高まるということ。
例えばwebサーバが複数あるとか。

>上の B = D で、これはどちらも同じバージョンのDLLなのですが・・。
ASP.NETのプロジェクトの開発で何か変更になったとき、
サブプロジェクトDのDLLを変更するのはいいけど、
その時点でBに反映させなければ、異なるバージョンの物でそれぞれが動作している
という気持ち悪い状況になるでしょ。

そういうやり方をしてるなら、Dが変更されたら、変更されたDLLをBとして反映する
必要があるから、結果的に複数のものを変更する必要があるんじゃないの？という話。
BとDが異なるバージョンのDLLで動作しているのが気持ち悪くない人というのは
そういう意味。

655:627
09/07/23 18:10:04
>>654
ああ、なるほど。意味がわかりました。

> その時点でBに反映させなければ、異なるバージョンの物でそれぞれが動作している
> という気持ち悪い状況になるでしょ。

確かにそれはそうですね。

私はdeployの作業自体はスクリプトを書いて自動化してあるのですが、そこに書き忘れたら、
というのはありますね。

656:nobodyさん
09/07/23 18:33:32
というか、Linq To SQLは終了の方向だから、
EntityFrameworkのほうで頑張るしかないな

657:nobodyさん
09/07/23 21:15:25
>652
DBMSは導入先の環境・都合で変わりうるでしょ。開発言語に関してはそれはまず有り得ない。
大体、「開発言語を変更しろ」なんてのは事実上「１から作り直せ」と同義なんだから、
ストアド部分だけ流用できたって、たいして嬉しくないよ。

658:nobodyさん
09/07/23 21:33:24
DBMSが具体的に何を差してるかわからんが、
データベースのソフト（MySQLたのOracleだのMSSQLだの）を差してるなら、
導入先の環境、都合でこれらがそんな頻繁に変わるか？

データだって移行せにゃいかんし、
そもそもクエリだってデータベース間で関数名や、その引数なんかに違いがあるんだから、
言語が統一ならどんなDBであってもまったく変わらないなんて完全な錯誤だと思うんだけど。
あるシステムでデータベースを異なる製品に変更しろなんて要求があったら、
1から作り直すのと同じだと思うし、あまりの仕打ちにそれ以上に腹が立つわｗ

659:nobodyさん
09/07/23 22:08:49
いつだってフルスクラッチ大好きな俺は大歓迎だ！
ただし、金と時間はくれよな！

660:nobodyさん
09/07/24 12:02:04
ASP.NETで開発しています。
JavaScriptで使っているデータを1日1回、DBから生成して .js ファイルとして書き出しておくことを考えています。

その .js ファイルを IIS7でホスティングすることになるのですが、
「DBから生成して .js ファイルとして書き出しておく」ときに、テンポラリに書き出して、
.NET FrameworkのFile.Copy(src , dst, overwrite = true)で前のファイルに上書きしようと考えています。

ところが、このファイルの書き出し中にこのファイルをクライアントブラウザから要求されて
IIS7が読み込もうとしたとき、コピー中の中途半端なファイルがクライアントブラウザに渡されます。

この挙動は望むものではなくて、出来れば、コピー前の古いファイルか、コピー後の新しいファイルかの
どちらかをクライアントブラウザに渡して欲しいのです。

これはIIS7の設定で解決するのでしょうか？それとも、File.Copyを使うのが良くないのでしょうか？

661:nobodyさん
09/07/24 15:08:26
rename してからコピーして rename
コピー中はファイル存在せず

662:nobodyさん
09/07/24 15:10:12
いや、少し違うか

hoge.new で予め作っておく
hoge.js → hoge.bak にリネーム
hoge.new → hoge.js にリネーム
hoge.bak を削除

663:nobodyさん
09/07/24 17:35:30
>>660
javascriptって.jsしか無理なんだっけ？
自分なら.jsファイル（もしくは変更されるデータ）をデータベースから取得し、
アクセスがあるたびに動的に生成するな

ファイルを作成するプログラムが、バッチ処理の役割も果たしていて、
日に1回の集計処理を行ってるとすると、若干厄介かもしれないけど

664:660
09/07/24 18:02:37
>>661-662
それだと hoge.js　→　hoge.bakにrename中にアクセスされるとnot foundになるのが
嫌なのです。その2つのrenameは実際にはほぼatomicに行なわれるとは思うのですが。

>>663
確かにデータベースから流しても良いのですが、そのオーバーヘッドが嫌なのです。

(自己解決)
NTFSは次のようにtransactionをサポートしているらしいので
面倒ですが、これを使うことにします..。

Enhance Your Apps With File System Transactions
URLﾘﾝｸ(msdn.microsoft.com)

665:nobodyさん
09/07/24 18:24:53
おーNTFSでファイルのトランザクションができるのかｗ
同じ.jsだとIEでキャッシュ扱いされそうな気がするんだが、その辺はどうなんだろ
レポート頼む

666:660
09/07/24 19:23:06
>>665
> 同じ.jsだとIEでキャッシュ扱いされそうな気がするんだが、その辺はどうなんだろ

それはIISのファイルのexpireの設定次第だと思います。

667:nobodyさん
09/07/24 19:40:49
へーその都度、生成されるaspxでも？

668:660
09/07/24 20:25:23
>>667
URLﾘﾝｸ(forums.techarena.in)

にサンプルがありますがファイルの拡張子ごとにexpireする時間を設定できるようです。
このうちjsのexpireを1hourぐらいに設定しておけば、>>665 の問題は解決するのではないかと。

669:nobodyさん
09/07/24 22:19:14 1HXeI2xc
生成し終わったファイルをコピーして別のファイル上書きするだけなら
そんな問題おきなさそうだけどなぁ。
ファイルシステム書き換えるだけでしょ。
Windows の Copy コマンドとか使えないのかな。

670:660
09/07/24 23:37:28
>>669
> 生成し終わったファイルをコピーして別のファイル上書きするだけなら
> そんな問題おきなさそうだけどなぁ。

起きます。System.IO.File.Copyでコピーした場合、ファイルコピーが開始されると
同時に、クライアントブラウザへの古いほうのファイルの転送が中断され、
結果として中途半端なファイルがクライアントブラウザに渡されます。

WindowsのCopyコマンドというのが何を指しているのかわかりませんが、
DOSプロンプトのcopyコマンドのことでしたら、これと同じ挙動のようです。

671:nobodyさん
09/07/25 01:29:42 WtyVOn10
＞自分なら.jsファイル（もしくは変更されるデータ）をデータベースから取得し、
＞アクセスがあるたびに動的に生成するな

うわ、死んだ方がいいなこいつｗ

672:nobodyさん
09/07/25 02:03:30
>>671
なんで？
それが駄目ならデータベースからデータを取得して、
動的に中身を生成するasp.netの全否定になると思うけど？

673:nobodyさん
09/07/25 02:15:27
ASP.NETの動作にDB接続が必須だったとは初耳だ

674:nobodyさん
09/07/25 02:19:13
ストアドってよく使われるもんなの？
個人的には全部ソースで作ればいいじゃんと思うんだけども。

675:nobodyさん
09/07/25 02:27:23
>>673
データベースからデータを取得してhtmlを生成する仕組みで動作してる
aspx全般のことを言ってるのに、asp=db必須なんて言うのは論理のすり替え

676:nobodyさん
09/07/25 03:11:46
>>674
ストアドに限らず、viewやテーブル値関数、トリガーを含めてなら便利だし、結構使う
問題なく動作してるなら、別にソースからでもいいんじゃない？

メリットはデータベースを一つのオブジェクトとみた場合、データの操作はデータに近いところで行うという、
可能な操作や状態のみ閲覧でき、実装を隠蔽できるOOPのメリットと併せて考えればわかりやすいと思うけど
あとは複数クエリの実行なら、ストアドのほうが処理が速いということかな
ASP.NETとはいえ、DBとWEBサーバは別だろうから、DB-WEB間のネットワークトラフィックを最低現にできるメリットもある

677:nobodyさん
09/07/25 03:12:12
>>675
んじゃーお前は何でもかんでもDBに突っ込んで毎回取りに逝けばいいよ。

678:nobodyさん
09/07/25 08:21:37 BV/bwvMa
俺頭悪いから
>>675 からなんで >>677 な意見が出るのか理解できない…。

>>673 はまぁ極端ではあるけど
>>672 の文章自体誤解を受けかねない部分はあるからまぁ仕方ないのかなって気はするけど。
まぁでもなんかとにかくかみつきたくてかみついてるような印象はあるか。

679:nobodyさん
09/07/25 11:37:23
>>671はjs「ファイルを動的に生成」ってところに
突っ込みたかったんだと思ったが…

680:nobodyさん
09/07/27 09:33:53
>>664
どこまで極めないといけないのか知らんが
js ファイルを作成する都度、別ファイル名にして、
aspx 側で食わせる js ファイル名を動的に変更させたらどう？

681:sage
09/07/27 10:06:33
TextBoxにもLabelにもなるユーザコントロールって作れないんスかね？
ReadOnlyのﾌﾟﾛﾊﾟｰﾃｨをtrueにすればLabel、falseにすればTextBox、みたいな。

TextBoxを変更不可にするんじゃどうしても見た目的に駄目なケースがあるんで。

682:nobodyさん
09/07/27 10:34:22 lA2VJ4lQ
動的にコントロール追加すればいいんじゃないの

683:nobodyさん
09/07/27 14:43:15
Repeaterでテキストボックスを動的に生成しています。
ボタンが押されたら内容をチェックして、何らかのエラーがあればエラーのあったテキスト
ボックスの背景色を変えたいんですが、方法が分かりません。

テキストボックスは動的に生成しているので、プロパティで変更することも出来ないみたいで。

684:nobodyさん
09/07/27 15:31:56
>>681
作れなくはないが、見た目だけならCSSで無理か？

>>683
FindControl

685:nobodyさん
09/07/27 15:33:45
>>681
TextBoxとLabelを配置したUserControl作って、ReadOnlyプロパティとTextプロパティを作って、
TextBox.Visible = !ReadOnly Labe.Visible = ReadOnlyすればいいじゃない

>>683
public List<TextBox> TextBoxList = new List<TextBox>();
protected void Page_Load(object sender, EventArgs e)
{
　for (int i = 0; i < this.Repeater1.Items.Count; i++)
　{
　　RepeaterItem ri1 = this.Repeater1.Items[i];
　　TextBox textBox = (TextBox)ri1.FindControl("TextBox1");
　　TextBoxList.Add(textBox);
　}
}
あとはお好きにどぞ

次ページ