2009/01/28

‫مشکل اضافه شدن اتوماتیک xmlns به web.config

در Visual Studio 2005 (و احتمالا نسخه ۲۰۰۸) هر بار که Web Site Administration Tool در یک پروژه وب اجرا شود عبارت xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0"‎ به عنوان یک attribute به تگ <configuration> در web.config اضافه می‌شود. علی الظاهر این کار از دید مایکروسافت یک باگ است و تگ فوق الذکر نباید چنین attributeی داشته باشد. وجود این xmlns در برنامه‌های وبی باعث می‌شود صفحاتی که از AjaxControlToolkit و به خصوص کنترل ConfirmButtonExtender استفاده کرده‌اند دچار مشکل شده و خطای زیر را نشان دهند:
The control with ID 'cbe1' requires a ScriptManager on the page. The ScriptManager must appear before any controls that need it.
برای حل این مشکل یعنی اضافه نشدن خودکار xmlns به تگ <configuration> باید فایل WebAdminPage.cs را از شاخه app_code باز کرده و خط:
config.NamespaceDeclared = true;



را در آن به صورت زیر تغییر دهید:



config.NamespaceDeclared = false;



این فایل را یا باید از آدرس C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\ASP.NETWebAdminFiles\App_Code پیدا کنید یا اگر مجموعه مدیریتی asp.net را به پروژه خود اضافه کرده‌اید آن را از داخل پروژه خود بیابید.


وجود xmlns فوق الاشاره در app.config برنامه‌های ویندوزی (ویندوز فرم، کنسول) هم مشکل زاست و باعث بروز خطای This application has failed to start because the application configuration is incorrect می‌شود:


This application has failed to start because the application configuration is incorrect


در مورد برنامه‌های ویندوزی نگرانی خاصی وجود ندارد. صرف برداشتن xmlns برای رفع خطا کفایت می‌کند. چون این attribute در حالت نمی‌تواند به طور خود به خود اضافه شود.








مراجع:
http://www.velocityreviews.com/forums/t121990-webconfig-schema-messages.html
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=102404
http://forums.asp.net/p/981068/1359525.aspx




2009/01/21

تجربه‌ای شیرین با «آژاکس»‏

asp.net ajax
تنها تجربه من با آژاکس مربوط به زمانی است که هنوز نسخه‌های «اطلس» روی بتا بودند و چون علاقه خودم هم بیشتر به سطح سرویس و Performance بود تا به UI در نتیجه چیز زیادی راجع به برنامه نویسی با آژاکس و سختی و آسان آن نمی‌دانستم. در طول چند روز گذشته مجبور شدم برای رفع یک خطا کمی با آژاکس درگیر شده و یک نمونه برنامه ساده بر اساس آن بنویسم. در این نمونه چند خطی که کاملا در حد یک Hello World بود، یک دکمه ساده روی صفحه گذاشته و با هر بار کلیک روی آن ساعت را روی خود دکمه نشان می‌دادم. یک کنترل ConfirmButtonExtender (از مجموعه کنترل‌های AjaxControlToolkit) را هم روی صفحه گذاشتم و به آن گفتم هر بار که روی دکمه نمایش ساعت کلیک شد از کاربر تایید بگیرد و اگر کاربر عملیات را لغو کرد هیچ اتفاق خاصی نیفتد در غیر این صورت ساعت را نمایش دهد. این هم کد آن که در VS 2008 نوشته شده است:
<%@ Page Language="C#" AutoEventWireup="true" 
CodeFile="Default.aspx.cs" Inherits="_Default" %>
<%@ Register Assembly="AjaxControlToolkit" 
Namespace="AjaxControlToolkit" TagPrefix="ajax" %>
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title>Untitled Page</title>
</head>
<body>
<form id="form1" runat="server">
<asp:ScriptManager ID="ScriptManager1" runat="server">
</asp:ScriptManager>
<ajax:ConfirmButtonExtender ID="cbe1" runat="server" 
ConfirmText="Are you sure???" TargetControlID="btn1">
</ajax:ConfirmButtonExtender>
<asp:Button runat="server" ID="btn1" 
OnClick="btn1_Click" />
</form>
</body>
</html>






خوبی این کد و بقیه نمونه‌هایی که در سایت ASP.NET AJAX Control Toolkit قرار دارد این است که در فایر فاکس هم به راحتی اجرا می‌شود. نمونه‌ی قابل اجرای همین کد در سایت آژاکس در اینجا قرارد دارد.





مراجع
نمونه برنامه‌های آژاکسی ASP.NET AJAX Control Toolkit




2009/01/12

‫خطای Unable to load client print control

MS SQL Reporting Services برای چاپ گزارشات از طریق صفحات وب از یک کنترل ActiveX به نام ClientPrintControl استفاده می‌کند. هر بار که کاربری بخواهد یکی از گزارشات را از طریق صفحات وب چاپ کند این کنترل به طور خودکار به کامپیوترش بارگذاری (download) شده و به طور اتوماتیک نصب می‌گردد. البته برای این کار باید Admin باشد و اجازه نصب ActiveX هم در تنظیمات IE صادر شده باشد در غیر این صورت خطای Unable to load client print control مشاهده می‌گردد. اما این‌ها تنها مواردی نیستند که موجب بروز این خطا می‌شوند…

unable to load client print control

یکی از اوقات خیلی نادری که ممکن است این اتفاق در آن به وقوع بپیوندد وقتی است که MS SQL Reporting Services از نسخه ۲۰۰۵ به ۲۰۰۸ ارتقا داده شده ولی کنترل‌های ReportViewerی که در لابلای صفحات ASPX وجود دارند همچنان از نسخه مخصوص ۲۰۰۵ استفاده می‌کنند. برای رفع مشکل باید تمام صفحات aspx و ascx پروژه به دنبال کد:

<%@ Register Assembly="Microsoft.ReportViewer.WebForms, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
Namespace="Microsoft.Reporting.WebForms" TagPrefix="rsweb" %>


جستجو شده و شماره نسخه آن از 8.0.0.0 به 9.0.0.0 که مخصوص MS SQL Reporting Services 2008 است عوض شود. فایل web.config هم باید برای موارد مشابه بررسی شود. پس از انجام این کار برای پیشگیری از وقوع هر نوع خطای احتمالی دیگر بهتر است Microsoft Report Viewer 2008 SP1 Redistributable هم در سرور نصب شود.

بعد از انجام همه این کارها ممکن بعضی کلاینت‌ها هنوز هم مشکل داشته باشند. برای رفع مشکل بایستی از طریق Command Prompt به شاخه C:\WINDOWS\Downloaded Program Files رفته، نخست انتهای فایل RSClientPrint-x86.inf مشاهده شده و از وجود تاریخ 2007 یا بالاتر در آن کسب اطمینان و سپس فایل rsclientprint.dll با کمک RegSvr32.exe در ویندوز Register گردد.



registering RsClientPrint.dll with regsvr32 



البته ممکن است این فایل‌ها در این شاخه موجود نباشند که در این صورت باید فایل ‎.cab آن از شاخه‌های نصب شده Reporting Services در ویندوز پیدا شده و پس از باز کردن زیپ آن در یکی از شاخه‌های هارد دیسک Register شود.




مراجع:
http://billfellows.blogspot.com/2008/10/unable-to-load-client-print-control.html
Microsoft Report Viewer 2008 SP1 Redistributable




2009/01/06

‫مهاجرت پروژه‌های دات نت از VS 2005 به 2008 و از Framework 2.0 به 3.5

migrate small برای این مهاجرت (ارتقا) باید ملاحظات زیادی را در نظر گرفته و دقت زیادی می‌کردم. چون حجم پروژه‌ها و solutionها خیلی زیاد بود و وابستگی‌های زیادی به هم داشتند و کم‌ترین اشتباه دردسرهای زیادی را درست می‌کردند. خصوصا این که کل سورس با ملاحظات امنیتی مختلفی روی Source Safe قرار داشتند. مشکلاتی را که در انجام این کار با آنها برخورد کرده‌ام را در ادامه خلاصه کرده‌ام:

۱- Build Break: از آخرین Build بعضی از پروژه‌ها وقت خیلی زیادی می‌گذشت و بعضی از آنها به دلیل تغییرات پروژه‌های دیگر build error پیدا کرده بودند. به خصوص پروژه‌های Initialization که همان اول‌ها و با عجله نوشته شده و بعد از آن خیلی کم استفاده شده بودند. بنابراین باید کل پروژه را در همان نسخه ۲۰۰۵ یک بار به طور کامل build کنم تا در ۲۰۰۸ فقط build errorهای ناشی از به روز رسانی را داشته باشم نه چیز دیگر.

۲- تعلیق کلیه فعالیت‌های توسعه و نگهداری: من سورس کد را از Source Safe گرفته بودم و می‌خواستم آن را در یک جای جدید VSS اضافه کنم بنابراین مجبور بودم به همه اعلام کنم تا پایان upgrade از هرگونه check in و check out خودداری و سورس‌های خود را عوض نکنند چون بعدا مجبور می‌شوند آنها را به طور دستی در نسخه ۲۰۰۸ وارد کنند و این یعنی استرس کاری و کمبود وقت در پروسه کاری مهاجرت از ۲۰۰۵ به ۲۰۰۸.

۳- پروژه‌های تست: به خاطر مشکلی که در convert فایل‌های ‎.vsmdi و localtestrun.testrunconfig داشتم و به خاطر قدیمی بودن پروژه‌های تست و استفاده کمی که از آنها می‌شد تبدیل پروژه‌های تست را بی‌خیال شده و آنها را unload کردم (به همین سادگی!).

۴- تغییر NameSpaceها: در یک مورد خاص NameSpace یکی از datasetها به طور خود به خود تغییر پیدا کرده و عبارت ‎.Entities به ته آن اضافه شده و این قضیه باعث شده بود که کل solution به دلیل عوض شدن این Name Space دچار build break شود. Name Space یک DataSet به طور خودکار از روی پروژه دربرگیرنده آن ساخته می‌شود و علی الظاهر روش ساخت این NameSpace در نسخه‌های ۲۰۰۵ و ۲۰۰۸ ویژوال استودیو با هم فرق کرده است. هر DataSet دارای دو NameSpace یکی برای خودش و دیگری برای اجزای آن است. این مشکل در مورد یکی از ریسورس‌ها (‎.resx) که در فولدر Properties یکی از پروژه‌ها بود هم اتفاق افتاده بود.

۵- جابجایی بعضی typeها و کلاس‌های داخلی دات نت: این قضیه فقط یک بار اتفاق افتاده بود و آن هم جابجایی System.Data.TypeTableBase از اسمبلی System.Data به System.Data.DataSetExtensions است. این جابجایی منجر به اضافه کردن reference جدید می‌شود.

۶- عوض کردن Target Framework از ‎.Net framework 2.0 به ‎.Net framework 3.5: که خود این کار هم کار وقت‌گیری بود چون باید تک تک پروژه‌ها را باز می‌کردم و این تنظیم را به طور دستی عوض می‌کردم. انجام این کار از طریق جستجو در فایل‌های ‎.csproj هم امکان پذیر نبود چون تا زمانی که این مقدار برابر ‎.Net Framework 2.0 باشد تگ TargetFrameworkVersion به xml آن اضافه نمی‌شد.

۷- عوض کردن جداگانه پروژه گزارشات از نسخه ۲۰۰۵ به نسخه ۲۰۰۸: که خود حدیث مفصلی داشت. برای کسب اطلاع بیشتر از جزییات موضوع به وبلاگ حاجلو مراجعه کنید.

۸- مشکلات مصیبت بار web.config: همانطور که می‌دانید شماره نسخه خیلی از کلاس‌ها و اسمبلی‌های دات نت در web.config نگهداری می‌شود. در حالت عادی خود ویژوال استودیو تقریبا همه شماره نسخه‌ها را به روز رسانی می‌کند ولی بعضی موارد هستند که به طور خودکار انجام نمی‌شوند و نیاز به دست کاری دستی دارند. قسمت بد این قضیه این است که بعضی از این موارد را نمی‌شود به این راحتی پیدا کرد و باید آنقدر مشکلات عجیب و غریب و لاینحل در برنامه دید و هزار تا منبع را بالا و پایین کرد تا منبع مشکل و راه حل آن پیدا شود. به عنوان مثال موردی که باعث شده بود یکی از صفحات خراب شده و واقعا گریه مرا درآورد، وجود عبارت ‎xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0" در نود configuration بود. وجود این عبارت در نرم افزار مبتنی بر framework 3.5 ما باعث شده بود یکی از صفحات دچار خطای Unable to cast object of type 'System.Web.Configuration.ScriptingScriptResourceHandlerSection' to type 'System.Web.Configuration.ScriptingScriptResourceHandlerSection'.شود.

۹- کنترل‌های شخص ثالث: در بعضی صفحات وب از کنترل‌هایی غیر از کنترل‌های مادرزاد دات نت استفاده شده است مثل کنترل‌های شخصی شرکت‌ها یا کنترل ReportViewer مایکروسافت. گاهی اوقات کد register این اسمبلی به جای web.config به طور مستقیم در همان صفحه وب (aspx,ascx) استفاده کننده قرار داده شده‌اند. در حین به روز رسانی باید به این مشکل هم توجه شده و اگر شماره نسخه کنترل‌ها عوض شده کد رجیستر هم به روز رسانی گردد. ما این مشکل را با کنترل مشاهده گزارشات MS SQL Reporting Services یعنی Microsoft.ReportViewer.WebForms داشتیم. چون نسخه آن را از 8.0.0.0 به 9.0.0.0 عوض نکرده و دچار مشکل Unable to load client print control شده بودیم. به این نوشته مسعود هم که در مورد همین مشکل است دقت کنید.

۱۰- ویرایش مخصوص framework 3.5 نرم افزارهای شخص ثالث: در حین این به روز رسانی بهتر است (بعضی وقت‌ها اجباری است) که نسخه مخصوص framework 3.5 کامپوننت‌ها و کتابخانه‌های متفرقه غیر مایکروسافتی به جای نسخه قبلی مورد استفاده قرار گیرد. مثل NHibernate و Enterprise Library.

۱۱- پیش فرض‌های قدیمی: گاهی اوقات در حین به روز رسانی‌ها، بعضی از پیش فرض‌های سیستم یا نرم افزار جدید عوض شده و کار را خراب می‌کنند. باید مواظب این طور تغییرات بود. بعضی از این پیش فرض‌ها عبارتند از: تغییر پیش فرض Call by Value و Call by Reference از VB6 به VB.Net که شهرت زیادی پیدا کرد، مقدار timeout در نسخه‌های جدیدتر Sql Server و…

 

پایان خوش: خوشبختانه تغییرات نسخه ۳٫۵ دات‌نت نسبت به نسخه ۲٫۰ چندان اساسی نبوده و بیشتر در حد توسعه Class Library بوده و این ارتقا تاثیر نامطلوبی روی کارکرد برنامه حداقل در طول دوره آزمایشی آن نداشته است.

پ. ن.: در مورد ۸ خطای The control with ID 'cbeDeleteLastAACDocument' requires a ScriptManager on the page. The ScriptManager must appear before any controls that need it. را هم داشتیم که با برداشتن آن xmlns حل شد.