محمد جواد ابراهیمی محمد جواد ابراهیمی
اشتراک‌ها
اضافه شدن قابلیت Package Registry به Github

Today, we’re excited to introduce GitHub Package Registry, a package management service that makes it easy to publish public or private packages next to your source code.

GitHub Package Registry is fully integrated with GitHub, so you can use the same search, browsing, and management tools to find and publish packages as you do for your repositories. You can also use the same user and team permissions to manage code and packages together. GitHub Package Registry provides fast, reliable downloads backed by GitHub’s global CDN. And it supports familiar package management tools: JavaScript (npm), Java (Maven), Ruby (RubyGems), .NET (NuGet), and Docker images, with more to come.

اضافه شدن قابلیت Package Registry به Github
‫۵ سال و ۵ ماه قبل، شنبه ۲۱ اردیبهشت ۱۳۹۸، ساعت ۱۰:۱۴
وحید نصیری وحید نصیری
مطالب
بهبود کارآیی برنامه‌های قدیمی که از SQL Server استفاده می‌کنند
برنامه‌های قدیمی، الزاما خیلی قدیمی هم نیستند؛ برنامه‌هایی هستند پر از کوئری‌های ذیل:
 SELECT * FROM table1 WHERE OrderDate ='12 Mar 2004'

SET @SQL = 'SELECT * FROM table2 WHERE OrderDate = ' + '''' + @Var + ''''
EXEC (@SQL)
ویژگی مهم این نوع کوئری‌ها که با جمع زدن رشته‌ها و یا مقدار دهی مستقیم فیلدها تشکیل شده‌اند، «غیر پارامتری» بودن آ‌ن‌ها است.
این نوع مشکلات با بکار گیری ORMها به نحو قابل توجهی کاهش یافته‌است؛ زیرا این نوع واسط‌ها در اغلب موارد، در آخر کار کوئری‌هایی پارامتری را تولید می‌کنند.


مشکل کوئری‌های غیر پارامتری چیست؟

استفاده‌ی وسیع از کوئری‌های غیرپارامتری با SQL Server، مشکلی را پدید می‌آورد به نام «Cache bloat» یا «کش پُف کرده» و این «پُف» به این معنا است که کش کوئری‌های اجرا شده‌ی بر روی SQL Server بیش از اندازه با Query plan‌های مختلف حاصل از بررسی نحوه‌ی اجرای بهینه‌ی آن‌ها پر شده‌است. هر کوئری که به SQL Server می‌رسد، جهت اجرای بهینه، ابتدا پردازش می‌شود و دستور العملی خاص آن، تهیه و سپس در حافظه کش می‌شود. وجود این کش به این خاطر است که SQL Server هربار به ازای هر کوئری رسیده، این عملیات پردازشی را تکرار نکند. مشکل از زمانی شروع می‌شود که SQL Server کوئری‌هایی را که از نظر یک برنامه نویس مانند هم هستند را به علت عدم استفاده‌ی از پارامترها، یکسان تشخیص نداده و برای هر کدام یک Plan جداگانه را محاسبه و کش می‌کند. این مساله با حجم بالای کوئری‌های رسیده دو مشکل را ایجاد می‌کند:
الف) مصرف حافظه‌ی بالای SQL Server که گاهی اوقات این حافظه‌ی اختصاص داده شده‌ی به کش کوئری‌ها به بالای یک گیگابایت نیز می‌رسد.
ب) CPU Usage بالای سیستم


سیستم قدیمی است؛ امکان تغییر کدها را نداریم.

بدیهی است بهترین راه حلی که در اینجا وجود دارد، پارامتری ارسال کردن کوئری‌ها به SQL Server است تا به ازای هر تغییری در مقادیر آن‌ها، این کوئری‌ها باز هم یکسان به نظر برسند و SQL Server سعی در محاسبه‌ی مجدد Plan آن‌ها نکند. اما ... اگر این امکان را ندارید، خود SQL Server یک چنین قابلیت‌هایی را به صورت توکار تدارک دیده‌است که باید فعال شوند.


فعال سازی پارامتری کردن خودکار کوئری‌ها در SQL Server

اگر نمی‌توانید کدهای یک سیستم قدیمی را تغییر دهید، SQL Server می‌تواند به صورت خودکار این‌کار را برای شما انجام دهد. در این حالت فقط کافی است یکی از دو دستور ذیل را اجرا کنید:
  --Forced
ALTER DATABASE dbName SET PARAMETERIZATION FORCED

--Simple
ALTER DATABASE dbName SET PARAMETERIZATION SIMPLE
حالت simple بیشتر جهت پارامتری کردن خودکار کوئری‌های select بکار می‌رود. اگر می‌خواهید تمام کوئری‌های select, insert, update و delete را نیز پارامتری کنید، باید از حالت forced استفاده نمائید.



فعال سازی بهبود کارآیی SQL Server با کوئری‌های Ad-Hoc زیاد

به کوئری‌های غیرپارامتری، کوئری‌های Ad-Hoc نیز گفته می‌شود. اگر سیستم فعلی شما، تعداد زیادی کوئری Ad-Hoc تولید می‌کند، می‌توان فشار کاری SQL Server را برای این مورد خاص، تنظیم و بهینه سازی کرد.
فعال سازی گزینه‌ی ویژه‌ی «Optimize for Ad hoc Workloads» سبب می‌شود تا SQL Server پس از مدتی به صورت خودکار کش Plan کوئری‌هایی را که به ندرت استفاده می‌شوند، حذف کند. همین مساله سبب آزاد شدن حافظه و بهبود کارآیی کلی سیستم می‌گردد. همچنین باید درنظر داشت که کش Plan کوئری‌ها نامحدود نیست و سقفی دارد. به همین جهت آزاد شدن آن، کش کردن کوئری‌هایی را که بیشتر استفاده می‌شوند، ساده‌تر می‌کند.
برای اعمال آن به یک بانک اطلاعاتی خاص، نیاز است دستورات ذیل را اجرا کرد:
 use dbName;
-- Optimizing for Ad hoc Workloads
exec sp_configure 'show advanced options',1;
RECONFIGURE;
go
exec sp_configure 'optimize for ad hoc workloads',1;
RECONFIGURE;
Go


برای مطالعه‌ی بیشتر
Fixing Cache Bloat Problems With Guide Plans and Forced Parameterization
Optimizing ad-hoc workloads
Optimizing for Ad hoc Workloads
‫۹ سال و ۳ ماه قبل، شنبه ۲۰ تیر ۱۳۹۴، ساعت ۱۶:۵۵
سالار ربال سالار ربال
اشتراک‌ها
وبینار برنامه نویسی واکنشی با RxJS

برنامه‌نویسی واکنشی (reactive) یک پارادایم برنامه‌نویسی اظهاری (declarative) است که در آن با جریان (stream)های داده و انتشار تغییرات کار می‌کنیم. این نوع برنامه‌نویسی بیشترین شباهت را به مدارهای سخت‌افزاری دارد. RxJS نمونه موفق و بسیار پرکاربرد Reactive Programming است که در برنامه‌نویسی JavaScript امروزی نقش پر رنگی دارد.

در این وبینار مبانی برنامه‌نویسی واکنشی و RxJS به زبان ساده ارائه می‌شود و پس از آن به چند نمونه از مسائل دنیای واقعی به شکل عملی پرداخته می‌شود. در انتها برخی مباحث پیشرفته‌تر هم عنوان خواهند شد.

زمان برگزاری: یکشنبه  23 آذر، ساعت 18:30 تا 20

محورهای اصلی این وبینار:

  • Introduction to Reactive Programming
  • Observables: Hot/Cold
  • Piping and Operators
  • High Order Observables
  • Advanced Topics
 
وبینار برنامه نویسی واکنشی با RxJS
‫۳ سال و ۹ ماه قبل، یکشنبه ۲۳ آذر ۱۳۹۹، ساعت ۰۳:۱۱
سالار ربال سالار ربال
اشتراک‌ها
خودکارسازی فرآیند اعمال GlobalQueryFilter در EF Core

Entity Framework Core 2.0 introduces global query filters that can be applied to entities when a model is created. It makes it easier to build multi-tenant applications and support soft deleting of entities. This blog post gives a deeper overview of how to use global query filters in real-life applications and how to apply global query filters to domain entities automatically. 

خودکارسازی فرآیند اعمال GlobalQueryFilter در EF Core
‫۶ سال و ۴ ماه قبل، یکشنبه ۶ خرداد ۱۳۹۷، ساعت ۱۵:۰۶
محمد رجبی محمد رجبی
مطالب
تعریف انبار داده Data Warehouse
در این مقاله در ادامه‌ی مطلبی که تحت عنوان «آموزش مفاهیم Data Warehouse» توسط آقای شاه قلی منتشر شده بود، به بررسی بیشتر مفهوم انبار داده ( Data Warehouse ) پرداخته می‌شود.

مقدمه
در سازمان ها، داده‌ها و اطلاعات معمولاً به دو شکل در سیستم‌ها پیاده سازی می‌گردد:
• سیستم‌های عملیاتی  OLTP:
این سیستم‌ها باعث می‌گردند تا چرخ کسب و کار بگردد. وجود این سیستم‌ها سبب می‌شود تا داده‌های مربوط به کسب و کار، به بانک اطلاعاتی وارد شوند. این سیستم‌ها عموماً:
o به دلیل کوتاهی عملیات دارای سرعت قابل توجهی می‌باشند.
o محیطی جهت ورود داده‌ها می‌باشند.
o معمولاً اپراتورها، استفاده کننده‌های آن هستند.
• سیستم‌های اطلاعاتی OLAP ، DW/BI، DSS :
این سیستم‌ها باعث می‌گردند تا چرخش کسب و کار را بنگرید. فلسفه بکارگیری این سیستم‌ها در سازمان این است که اطلاعات مورد نیاز مدیران، از درون داده‌های سیستم‌های عملیاتی موجود، استخراج گردد. این سیستم‌ها عموماً:
o به دلیل آنالیز حجم انبوهی از داده ها، معمولاً کندتر از سیستم‌های عملیاتی می‌باشند.
o محیطی جهت تولید گزارشات تحلیلی و آماری می‌باشند.
o معمولاً مدیران و تصمیم گیرندگان سازمان ها، استفاده کنندگان آن می‌باشند.
سیستم‌های عملیاتی در جامعه ما سابقه بیشتری داشته و متخصصین فناوری اطلاعات عموماً با طراحی و تولید چنین سیستم هایی آشنایی کافی دارند. متاسفانه جایگاه سیستم‌های اطلاعاتی در جامعه ما کمتر شناخته شده و متخصصین فناوری اطلاعات بندرت با مفاهیم و نحوه پیاده سازی آن آشنایی دارند.
این نکته حائز اهمیت است که سیستم‌های اطلاعاتی یک سیستم یا محصول نیستند که بتوان آنها را خریداری کرد. بلکه یک راهبرد (Solution, Approach) هستند و در حقیقت هر راهبردی مربوط به یک نوع کسب و کار (Business) و یا سازمان می‌باشد و نمی‌توان فرمول واحدی را برای حتی سازمان‌های مشابه، ارائه نمود.

گارتنر در ابتدای سال 2011 گزارشی را منتشر کرده که نشان میدهد بازار BI با 9.7 % رشد، ارزشی بالغ بر 10.8 بیلیون دلار داشته، ولی متاسفانه پروژه‌های آن به طور متوسط با 75% شکست مواجه شده است. در حالیکه 4 سال پیش، این رقم حدود 50% بود. این موسسه BI را پنجمین اولویت مدیران IT ذکر کرده است.

مفاهیم و مباحث مربوط به Data Warehouse به اواسط دهه 1980 برمی گردد، به زمانی که IBM تحقیقاتی را در این زمینه شروع کرد و نتیجه آنرا «Information Warehouse» نامید و هنوز هم در برخی منابع از این واژه بجای Data Warehouse استفاده می‌شود. از این پس برای راحتی از اختصار DW بجای Data Warehouse استفاده می‌شود. انبارهای داده جهت رفع نیاز رو به رشد مدیریت داده‌ها و اطلاعات سازمانی که توسط پایگاه‌های داده سیستم‌های عملیاتی غیر ممکن بود، ساخته شدند.

انبار داده به مجموعه ای از داده‌ها گفته می‌شود که از منابع مختلف اطلاعاتی سازمان جمع آوری، دسته بندی و ذخیره می‌شود. در واقع یک انبار داده مخزن اصلی کلیه داده‌های حال و گذشته یک سازمان می‌باشد که برای همیشه جهت انجام عملیات گزارش گیری و آنالیز در دسترس مدیران می‌باشد. انباره‌های داده حاوی داده هایی هستند که به مرور زمان از سیستم‌های عملیاتی آنلاین سازمان، استخراج می‌شوند. بنابراین سوابق کلیه اطلاعات و یا بخش عظیمی از آنها را می‌توان در انباره داده‌ها مشاهده نمود.
از آنجائیکه انجام عملیات آماری و گزارشات پیچیده دارای بار کاری بسیار سنگینی برای سرورهای پایگاه داده می‌باشند، وجود انبار داده سبب می‌گردد که این گونه عملیات تاثیری بر فعالیت برنامه‌های کاربردی سازمان نداشته باشد.
همانگونه که پایگاه داده سیستم‌های عملیاتی سازمان (برنامه‌های کاربردی) به گونه ای طراحی می‌شوند که انجام تغییر، حذف و اضافه داده به سرعت صورت پذیرد، در مقابل انبار داده‌ها دارای معماری ویژه ای می‌باشند که موجب تسریع انجام عملیات آماری و گزارش گیری می‌شود. در حقیقت می‌توان اینگونه بیان نمود که انباره داده یک مخزن فعال و هوشمند از اطلاعات است که قادر است اطلاعات را از محیط‌های گوناگون جمع آوری و مدیریت کرده و نهایتا پخش نماید و در صورت لزوم نیز سیاست‌های تجاری را روی آنها اجرا نماید.

Bill Inmon:
او را پدر DW می‌نامند، از دیدگاه او DW هسته مرکزی چیزی است که او آنرا CIF اختصار (Corporate Information Factory) می‌نامد، که پایه و اساس BI بر مبنای آن قرار دارد. وی از طرفداران Top-Down Design می‌باشد که معتقد است در زمان طراحی باید با دیدی سازمانی، CIF را مدل سازی، ولی بصورت دپارتمانی پیاده سازی کرد (Think Globally, Implement Locally). در این نوع طراحی از DW به Data Mart خواهیم رسید.

Ralph Kimball Ph.D:
به نظر وی DW چیزی نیست جز یک کپی از داده‌های عملیاتی که به طرز خاصی برای گزارشات و تحلیل‌های آماری، آماده و ساختمند شده است. به بیان دیگر DW سیستمی است جهت استخراج، پالایش، تطبیق و تحویل اطلاعات منابع داده ای به یک بانک اطلاعاتی Dimensional و اجرای Query و گزارشات آماری و تحلیلی برای اهداف تصمیم گیری و استراتژیک سازمان.
وی معرفی کننده یکی از اساسی‌ترین مفاهیم طراحی یعنی Dimensional Modeling است؛ ماحصل چنین ایده ای، اساس شکل گیری مدلی است که امروزه کارشناسان آنرا به نام Cube می‌شناسند. وی از طرفداران Bottom-Up Design است که در این نگرش از Data Mart به DW می‌رسیم. این روش به نظر عملی‌تر از روشی می‌باشد که به یکباره DW جامع و کامل برای اهداف سازمانی طراحی و پیاده سازی گردد.

تعریف انبار داده:
W.H.Inmon پدر DW آنرا چنین تعریف می‌کند:
The Data Warehouse is a collection of Integrated, Subject-Oriented databases designed to support the DSS function, where each unit of data is Non-Volatile and relevant to some moment in Time
از تعریف فوق دو مورد دیگر نیز به طور ضمنی استنباط می‌شود:
o انبار داده به طور فیزیکی، کاملاً جدا از سایر سیستم‌های عملیاتی است.
o داده‌های DW مجموعه ای Aggregated و Atomic از داده‌های تراکنش‌های سیستم‌های عملیاتی است که سوای کاربرد آنها در سیستم‌های عملیاتی، برای مقاصد مدیریتی نیز استفاده خواهد شد.

به بیان دیگر DW راهبردی است که دسترسی آسان به اطلاعات درست (Right Information)، در زمانی درست (Right Time) ، به کاربران درست (Right Users)، را فراهم می‌آورد تا «تصمیم گیری سازمانی» قابل انجام باشد. DW صرفاً یک محصول نرم افزاری و یا سخت افزاری نیست که بتوان آنرا خریداری نمود بلکه فراتر از آن و در حقیقت یک محیط پردازشی می‌باشد که کاربران می‌توانند از درون آن اطلاعات مورد نیاز خود را بیابند.
DW اطلاعات خود را از سایر بانک‌های اطلاعاتی از نوع OLTP و یا سایر DW‌های لایه پایین‌تر و به صورت دسته ای (Batch) و یا انبوه (Bulk Loading) جمع آوری می‌کند. یک DW به صورت سنتی باید شامل داده‌های Historic سازمان باشد و می‌توان اینگونه بیان نمود که در DW هرچه داده‌های قدیمی‌تری موجود باشد، اعتبار تحلیل‌های آماری سیستم افزایش خواهد یافت.

داده‌های سیستم عملیاتی را نمی‌توان بلافاصله درون بانک اطلاعاتی DW لود نمود، چنین داده هایی باید آماده سازی، پالایش و همگون گردند تا شرایط لود در DW را داشته باشند. حداقل کاری که انتظار داریم یک DW در مورد داده‌ها برای ما برآورده سازد شامل موارد زیر است:
o استخراج داده‌ها از منابع مختلف (مبدإ)
o تبدیل داده‌ها به فرمتی یکسان
o لود داده‌ها به جداول مربوطه (مقصد)
با هر با اجرای پروسه فوق یکی از سه مورد زیر، بسته به نیاز طراحی و محدودیت‌های تکنولوژی رخ خواهد داد:
o تمام داده‌ها در DW با داده‌های جدید جایگزین خواهند گردید(Full Load, Initial Load, Full Refresh).
o داده‌های جدید به داده‌های موجود اضافه خواهند گردید (Incremental Load (Inserted data.
o نسخه جدیدی از داده‌های کنونی به سیستم اضافه خواهند گردید (Incremental Load (Updated data.


ویژگی‌های داده‌های درون DW
داده‌های DW از نگاه Inmon دارای 4 ویژگی اصلی زیر هستند:
o فقط خواندنی (Non-Volatile):
هیچ رکوردی و یا داده ای Update نخواهد شد و صرفاً رکوردهایی که محتوای مقادیر جدید داده‌ها هستند، به سیستم اضافه خواهند شد.
o موضوع گرا (Subject-Oriented):
منظور از «موضوع» پایه‌های اساسی یک کسب و کار هستند، به شکلی که با حذف یکی از این پایه ها، شاید ماهیت آن کسب و کار از ریشه دگرگون شود. برای مثال موضوعاتی چون «مشتری» و یا «بیمه نامه» برای شرکت‌های بیمه.
o جامع (Integrated):
باید تمامی کدهایی که در سیستم‌های عملیاتی وجود دارند و معانی یکسانی دارند، برای مثال کد جنسیت، در DW به یک روش ذخیره و نمایش داده شوند.
o زمانگرا (Time Variant):
هر رکورد باید حاوی فیلد و یا کلیدی باشد که نمایانگر این باشد که این رکورد در چه زمانی ایجاد، استخراج و ذخیره شده است. از آنجا که داده‌های درون سیستم‌های عملیاتی آخرین و به روز‌ترین داده هر سیستم میباشد، نیازی به وجود چنین عنصری در سیستم‌های OLTP احساس نمی‌گردد، ولی چون در DW تمام داده‌های نسخ قدیمی داده‌های سیستم‌های عملیاتی موجود می‌باشد، باید حتماً مشخص گردد که هر داده ای در سیستم‌های عملیاتی در چه زمانی، چه مقادیری داشته است. این عنصر زمانی کمک می‌کند تا بتوانیم:
o گذشته را آنالیز کنیم.
o اطلاعات مربوط به حال حاضر را بدست آوریم.
o آینده را پیش بینی کنیم.

منبع: کتاب آقای خشایار جام سحر با عنوان بانک داده تجمیعی
Comparison  Kimball vs. Inmon

Inmon
Continuous & Discrete Dimension Management
Define data management via dates in your data
Continuous time  
  When is a record active
Start and end dates
Discrete time  
 A point in time
  Snapshot
 
Kimball
Slowly Changing Dimension Management
Define data management via versioning
Type I  
  Change record as required
  No History
Type II  
  Manage all changes
 History is recorded
Type III  
  Some history is parallel
  Limit to defined history


Kimball 
Inmon 
Business-Process-Oriented
Stresses Dimensional Model, Not E-R 		Subject-Oriented
Integrated
Non-Volatile
Time-Variant
Bottom-Up and Evolutionary 
Top-Down 
Integration Achieved via Conformed Dimensions 
Integration Achieved via an Assumed Enterprise Data Model 
Star Schemas Enforce Query Semantics 
Characterizes Data marts as Aggregates 
Kimball
 		Inmon
Bottom-up
 Top-down
 Overall approach
Data marts model a business process;enterprise is achieved with conformed dims
 Enterprise-wide DW feeds departmental DBs
 Architectural structure
Fairly simple
 Quite complex
 Complexity of method
Process oriented
 Subject or data driven
 Data orientation
Dimensional modeling; departs from traditional relational modeling
 Traditional  ERDs and DIS
Tools
High
 Low
 End user accessibility
Slowly Changing
 Continuous & Discrete
 Timeframe
Dimension keys
 Timestamps
 Methods
‫۱۰ سال و ۶ ماه قبل، دوشنبه ۱۵ اردیبهشت ۱۳۹۳، ساعت ۱۵:۰۰
وحید نصیری وحید نصیری
مطالب
پیدا کردن لیست SQL server های نصب شده در یک شبکه


با آمدن SQL server 2008 استفاده از کتابخانه SQL-DMO برای انجام یک سری از امور بر روی اس کیوال سرور با استفاده از برنامه نویسی منسوخ شد. یکی از توانایی‌های این کتابخانه لیست کردن سرورهای اس کیوال (قابل دسترسی) موجود در شبکه بود.
برای مثال توسط این کتابخانه به صورت زیر می‌توان اینکار را انجام داد:
در قطعه کد زیر فرض بر این است که ارجاعی به کتابخانه sqldmo را در برگه com مربوط به project->add reference اضافه کرده‌اید:

   using SQLDMO;
   using System.Collections.Generic;

   public static List<string> GetSQLServersList2()
   {
       List<string> result = new List<string>();
       ApplicationClass sqlApp = new ApplicationClass();
       NameList lst = sqlApp.ListAvailableSQLServers();
       for (int i = 1; i <= lst.Count; i++)
           result.Add(lst.Item(i));
       lst = null;
       sqlApp = null;

       return result;

   }

با منسوخ شدن این کتابخانه COM (که تنها تا اس کیوال سرور 2005 پشتیبانی می‌شود)، در نگارش‌های جدید (و قدیم) اس کیوال سرور، با استفاده از قطعه کد زیر می‌توان لیست تمام SQL server های نصب شده در یک شبکه به همراه instance های آنها را بدست آورد.

using System.Collections.Generic;
using System.Data;
using System.Data.Sql;

public class CListServers
{
   public static List<string> GetSQLServersList()
   {
       List<string> result = new List<string>();

       // Retrieve the enumerator instance and then the data.
       var instance = SqlDataSourceEnumerator.Instance;
       var table = instance.GetDataSources();

       // Display the contents of the table.
       foreach (DataRow row in table.Rows)
       {
           result.Add(string.Format("{0}\\{1}", row[0], row[1]));
       }

       return result;
   }
}

راه دیگر:
کتابخانه COM یاد شده (SQL-DMO) در SQL server 2008 با کتابخانه SMO جایگزین شده است.
در این حالت خواهیم داشت:

using System.Collections.Generic;
using System.Data;
using Microsoft.SqlServer.Management.Smo;

public class CListServers
{
   public static List<string> GetSQLServersListSMO()
   {
       List<string> result = new List<string>();
       DataTable dt = SmoApplication.EnumAvailableSqlServers(false);
       if (dt.Rows.Count > 0)
       {
           foreach (DataRow dr in dt.Rows)
           {
               result.Add(dr["Name"].ToString());
           }
       }
       return result;
   }
}

تقریبا کلیه اعمالی که از طریق management studio قابل انجام هستند با کمک این کتابخانه نیز از طریق برنامه نویسی می‌توان به آن‌ها پرداخت. برای مثال تهیه اسکریپت کلیه جداول ، تریگرها و غیره.

‫۱۵ سال و ۱۲ ماه قبل، سه‌شنبه ۲۸ آبان ۱۳۸۷، ساعت ۱۷:۳۴
امیر قراجه داغی امیر قراجه داغی
مطالب
حل مشکل ویژوال استودیو در سیستمهایی که از رزولوشن (DPI) بالا و مانیتور های 4K استفاده می کنند
مدتی بود بر روی یک پروژه‌ی اتوماسیون اداری در VB.NET کار می‌کردیم. پروژه‌ی ما بر روی سیستمی با رزولوشن بالا  2160 * 3840 و مانیتور 4K قرار داشت. بعد از اینکه لایه بندی و کد‌های نرم افزار نوشته شد، نوبت به طراحی اینترفیس پروژه رسید. با مشکلی عجیب روبرو شدیم، به این صورت که در قسمت طراحی ویژوال استودیو، منوها، دکمه‌ها و ... بیش از حد معمول کوچک و به هم ریخته بود. ولی زمانیکه پروژه اجرا می‌شد، نسبت به طراحی که در سمت وِیژوال استودیو انجام داده بودیم، دکمه‌ها  بزرگتر و منوها بزرگتر و شکسته شده بودند. در حقیقت، سمت طراحی و سمت اجرای پروژه، هم خوانی نداشتند. در حالیکه ما قبلا بر روی مانیتور‌های HD و رزولوشن‌ها HD، هیچ مشکلی در طراحی و اجرای پروژه نداشتیم و هم خوانی لازم را باهم داشتند. بعد از جستجوهای متعدد، به این مطلب پی بردیم که این مشکل بیشتر برنامه نویسانی هست که از سیستم‌هایی با رزولوشن بالا و مانیتور‌های 4K استفاده می‌کنند و پاسخ مناسبی به کاربران داده نشده است. با تست راه‌های متعدد و جستجوهای پی در پی، به پاسخ قطعی رسیدیم و خواستم این مطلب  را به صورت مقاله‌ای کوتاه، با شما به اشتراک بگذارم.
مشخصات سیستمی که مشکل زیر را دارد : ویندوز 10  نسخه  Enterprise  x64 و ویژوال استودیو 2015 نسخه  Enterprise 
نمونه اسکرین شات گرفته شده که مشکل یکی از کاربران ایرانی بود و برای حل مشکل خود، اسکرین شات صفحه نمایش خود را قرار داده بود و به پاسخ قطعی نرسیده بود:

  اگر ملاحظه کنید، تصویر سمت راست، از پروژه‌ای بر روی VirtualBox با رزولوشن و DPI پایین در دیزاین ویژوال استودیو و تصویر سمت چپ از همان پروژه در دیزاین ویژوال استودیو با رزولوشن بالا و مانیتور 4K تهیه شده‌است و ملاحظه می‌کنید که پروژه به هم ریخته است و این مشکل در خیلی از برنامه‌های دیگر نیز موجود می‌باشد؛ مانند SQL SERVER و ...
 نمونه اسکرین شات گرفته شده از بعضی پنجره‌های SQL server 

حال برای رفع این مشکل چه باید کرد؟ به صورت زیر عمل می‌کنیم  

  1. به مسیر زیر در رجیستری مراجعه می‌کنیم :     
HKEY_LOCAL_MACHINE > SOFTWARE > Microsoft > Windows > CurrentVersion > SideBySide
 و رایت کلیک کرده  NEW > DWORD (32 bit) Value  انتخاب کرده و نام را PreferExternalManifest وارد کرده و Value را بر روی 1 قرار می‌دهیم .

     

2. نرم افزار Resourcehacke را دانلود کرده و آن‌را اجرا کرده و از قسمت File، بر روی Open کلیک کرده و مسیر ویژوال استودیو را به نرم افزار داده و  Ok را انتخاب می‌کنیم .  
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE


بعد از بارگذاری اطلاعات ویژوال استودیو در نرم افزار  Resourcehacke، از سمت چپ بر روی Manifest و 1:1033 کلیک کرده و dpiAware را بر روی False قرار می‌دهیم . 
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 
  <application xmlns="urn:schemas-microsoft-com:asm.v3"> 
    <windowsSettings> 
      <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">False</dpiAware> 
    </windowsSettings> 
  </application> 
</assembly>

ودر آخر سیستم را ریستارت کرده و با همان رزولوشن بالا و مانیتور 4K، ویژوال استودیو را اجرا می‌کنیم و ملاحظه میکنیم که مشکل خاصی وجود ندارد و سمت دیزاین با سمت اجرای پروژه همخوانی دارد و همسان می‌باشد.

‫۸ سال و ۴ ماه قبل، دوشنبه ۳۱ خرداد ۱۳۹۵، ساعت ۱۳:۴۰