- در اینجا ابتدا فضای نام اصلی پروژهی جاری ذکر شدهاست. به همین جهت است که عنوان کردهاند اگر منابع در اسمبلی جاری هستند، نباید مجددا این فضای نام پیش فرض ذکر شود.
- سپس نام Resources را مشاهده میکنید. بنابراین چیزی که بارگذاری میشود، یک منبع مدفون شدهی در یک فایل dll است و نه اینکه در زمان اجرا به پوشهی Resources مراجعه میشود. این پوشهی Resources در اینجا در حد یک جزء از نام کامل بیشتر مطرح نیست.
- در آخر هم نام کامل نوع مدنظر ذکر شدهاست. مثلا نام کامل ViewModel مورد استفاده.
- این نکات در مورد فایلهای Shared هم مطرح هستند.
- من چون نام پوشهی Views را به Features تغییر دادهام، دومین فایل لیست شدهی در اینجا، چنین نامی را دارد (بجای Views استاندارد).
بنابراین اگر اطلاعات را به اسمبلیهای دیگر منتقل میکنید:
- به ذکر کامل فضاهای نام دقت داشته باشید.
- بررسی کنید آیا اسمبلی منبع با اسمی شبیه به Core1RtmEmptyTest.resources.dll در پوشهی bin\Debug\netcoreapp1.0\fa موجود هست یا خیر؟ و اگر موجود است، بررسی کنید چه محتوایی در آن ثبت شدهاست.
یکی کردن اسمبلیهای یک پروژهی WPF
- یک try/catch در قسمت بارگذاری اسمبلی قرار دهید تا بهتر منبع مشکل را شناسایی کنید. یک مثال
- شخص دیگری در اینجا گزارش داده اگر Generate serialization assembly در قسمت تنظیمات پروژه، ذیل Build > Output فعال است، باید خاموش شود تا پروژه کرش نکند.
- اگر نوع اسمبلی، PCL است (Portable Class Library)، باز هم روش Assembly.Load به نحوی که در مطلب ذکر شده کار نمیکند و باید به صورت ذیل اصلاح شود:
private static Assembly loadEmbeddedAssembly(string name) { if (name.EndsWith("Retargetable=Yes")) { return Assembly.Load(new AssemblyName(name)); } // Rest of your code //... }
[MethodImpl(MethodImplOptions.NoOptimization)]
هر بانک اطلاعاتی باید Migration و Context خاص خودش را داشته باشد
تامین کنندهی بانکهای اطلاعاتی مختلف، عموما تنظیمات خاص خودشان را داشته و همچنین دستورات SQL متفاوتی را نیز تولید میکنند. به همین جهت نمیتوان از یک تک Context، هم برای SQLite و هم SQL Server استفاده کرد. به علاوه قصد داریم اطلاعات Migrations هر کدام را نیز در یک اسمبلی جداگانه قرار دهیم. در یک چنین حالتی EF نمیپذیرد که Context تولید کنندهی Migration، در اسمبلی دیگری قرار داشته باشد و باید حتما در همان اسمبلی Migration قرار گیرد. بنابراین ساختار پوشه بندی مثال جاری به صورت زیر خواهد بود:
- در پوشهی EFCoreMultipleDb.DataLayer فقط اینترفیس IUnitOfWork را قرار میدهیم. از این جهت که وقتی قرار شد در برنامه چندین Context تعریف شوند، لایهی سرویس برنامه قرار نیست بداند در حال حاضر با کدام Context کار میکند. به همین جهت است که تغییر بانک اطلاعاتی برنامه، تغییری را در کدهای اصلی آن ایجاد نخواهد کرد.
- در پوشهی EFCoreMultipleDb.DataLayer.SQLite کدهای Context و همچنین IDesignTimeDbContextFactory مخصوص SQLite را قرار میدهیم.
- در پوشهی EFCoreMultipleDb.DataLayer.SQLServer کدهای Context و همچنین IDesignTimeDbContextFactory مخصوص SQL Server را قرار میدهیم.
برای نمونه ابتدای Context مخصوص SQLite چنین شکلی را دارد:
public class SQLiteDbContext : DbContext, IUnitOfWork { public SQLiteDbContext(DbContextOptions options) : base(options) { } public virtual DbSet<User> Users { set; get; }
namespace EFCoreMultipleDb.DataLayer.SQLite.Context { public class SQLiteDbContextFactory : IDesignTimeDbContextFactory<SQLiteDbContext> { public SQLiteDbContext CreateDbContext(string[] args) { var basePath = Directory.GetCurrentDirectory(); Console.WriteLine($"Using `{basePath}` as the BasePath"); var configuration = new ConfigurationBuilder() .SetBasePath(basePath) .AddJsonFile("appsettings.json") .Build(); var builder = new DbContextOptionsBuilder<SQLiteDbContext>(); var connectionString = configuration.GetConnectionString("SqliteConnection") .Replace("|DataDirectory|", Path.Combine(basePath, "wwwroot", "app_data")); builder.UseSqlite(connectionString); return new SQLiteDbContext(builder.Options); } } }
تنظیمات رشتههای اتصالی بانکهای اطلاعاتی مختلف
در اینجا محتویات فایل appsettings.json را که در آن تنظیمات رشتههای اتصالی دو بانک SQL Server LocalDB و همچنین SQLite در آن ذکر شدهاند، مشاهده میکنید:
{ "Logging": { "LogLevel": { "Default": "Warning" } }, "AllowedHosts": "*", "ConnectionStrings": { "SqlServerConnection": "Data Source=(LocalDB)\\MSSQLLocalDB;Initial Catalog=ASPNETCoreSqlDB;AttachDbFilename=|DataDirectory|\\ASPNETCoreSqlDB.mdf;Integrated Security=True;MultipleActiveResultSets=True;", "SqliteConnection": "Data Source=|DataDirectory|\\ASPNETCoreSqliteDB.sqlite", "InUseKey": "SqliteConnection" } }
یک کلید InUseKey را هم در اینجا تعریف کردهایم تا مشخص باشد در ابتدای کار برنامه، کلید کدام رشتهی اتصالی مورد استفاده قرار گیرد. برای مثال در اینجا کلید رشتهی اتصالی SQLite تنظیم شدهاست.
در این تنظیمات یک DataDirectory را نیز مشاهده میکنید. مقدار آن در فایل Startup.cs برنامه به صورت زیر بر اساس پوشهی جاری تعیین میشود و در نهایت به wwwroot\app_data اشاره خواهد کرد:
var connectionStringKey = Configuration.GetConnectionString("InUseKey"); var connectionString = Configuration.GetConnectionString(connectionStringKey) .Replace("|DataDirectory|", Path.Combine(Directory.GetCurrentDirectory(), "wwwroot", "app_data"));
دستورات تولید Migrations و به روز رسانی بانک اطلاعاتی
چون تعداد Contextهای برنامه بیش از یک مورد شدهاست، دستورات متداولی را که تاکنون برای تولید Migrations و یا به روز رسانی ساختار بانک اطلاعاتی اجرا میکردید، با پیام خطایی که این مساله را گوشزد میکند، متوقف خواهند شد. راه حل آن ذکر صریح Context مدنظر است:
برای تولید Migrations، از طریق خط فرمان، به پوشهی اسمبلی مدنظر وارد شده و دستور زیر را اجرا کنید:
For /f "tokens=2-4 delims=/ " %%a in ('date /t') do (set mydate=%%c_%%a_%%b) For /f "tokens=1-2 delims=/:" %%a in ("%TIME: =0%") do (set mytime=%%a%%b) dotnet build dotnet ef migrations --startup-project ../EFCoreMultipleDb.Web/ add V%mydate%_%mytime% --context SQLiteDbContext
دو سطر اول آن، زمان اجرای دستورات را به عنوان نام فایلها تولید میکنند.
پس از تولید Migrations، اکنون نوبت به تولید بانک اطلاعاتی و یا به روز رسانی بانک اطلاعاتی موجود است:
dotnet build dotnet ef --startup-project ../EFCoreMultipleDb.Web/ database update --context SQLServerDbContext
بدیهی است این رویه را پس از هربار تغییراتی در موجودیتهای برنامه و یا تنظیمات آنها در Contextهای متناظر، نیاز است مجددا اجرا کنید. البته اجرای اولین دستور اجباری است؛ اما میتوان دومین دستور را به صورت زیر نیز اجرا کرد:
namespace EFCoreMultipleDb.Web { public class Startup { public void Configure(IApplicationBuilder app, IHostingEnvironment env) { applyPendingMigrations(app); // ... } private static void applyPendingMigrations(IApplicationBuilder app) { var scopeFactory = app.ApplicationServices.GetRequiredService<IServiceScopeFactory>(); using (var scope = scopeFactory.CreateScope()) { var uow = scope.ServiceProvider.GetService<IUnitOfWork>(); uow.Migrate(); } } } }
namespace EFCoreMultipleDb.DataLayer.SQLite.Context { public class SQLiteDbContext : DbContext, IUnitOfWork { // ... public void Migrate() { this.Database.Migrate(); } } }
مرحلهی آخر: انتخاب بانک اطلاعاتی در برنامهی آغازین
پس از این تنظیمات، قسمتی که کار تعریف IUnitOfWork و همچنین DbContext جاری برنامه را انجام میدهد، به صورت زیر پیاده سازی میشود:
namespace EFCoreMultipleDb.Web { public class Startup { public void ConfigureServices(IServiceCollection services) { services.AddScoped<IUsersService, UsersService>(); var connectionStringKey = Configuration.GetConnectionString("InUseKey"); var connectionString = Configuration.GetConnectionString(connectionStringKey) .Replace("|DataDirectory|", Path.Combine(Directory.GetCurrentDirectory(), "wwwroot", "app_data")); switch (connectionStringKey) { case "SqlServerConnection": services.AddScoped<IUnitOfWork, SQLServerDbContext>(); services.AddDbContext<SQLServerDbContext>(options => { options.UseSqlServer( connectionString, dbOptions => { var minutes = (int)TimeSpan.FromMinutes(3).TotalSeconds; dbOptions.CommandTimeout(minutes); dbOptions.EnableRetryOnFailure(); }); }); break; case "SqliteConnection": services.AddScoped<IUnitOfWork, SQLiteDbContext>(); services.AddDbContext<SQLiteDbContext>(options => { options.UseSqlite( connectionString, dbOptions => { var minutes = (int)TimeSpan.FromMinutes(3).TotalSeconds; dbOptions.CommandTimeout(minutes); }); }); break; default: throw new NotImplementedException($"`{connectionStringKey}` is not defined in `appsettings.json` file."); } services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2); }
آزمایش برنامه
ابتدا کدهای کامل این مطلب را از اینجا دریافت کنید: EFCoreMultipleDb.zip
سپس آنرا اجرا نمائید. چنین تصویری را مشاهده خواهید کرد:
اکنون برنامه را بسته و سپس فایل appsettings.json را جهت تغییر مقدار InUseKey به کلید SqlServerConnection ویرایش کنید:
{ "ConnectionStrings": { // … "InUseKey": "SqlServerConnection" } }
مقدار username، در contextهای هر کدام از این بانکهای اطلاعاتی، با مقدار متفاوتی به عنوان اطلاعات اولیهی آن ثبت شدهاست. سرویسی هم که اطلاعات آنرا تامین میکند، به صورت زیر تعریف شدهاست:
namespace EFCoreMultipleDb.Services { public interface IUsersService { Task<User> FindUserAsync(int userId); } public class UsersService : IUsersService { private readonly IUnitOfWork _uow; private readonly DbSet<User> _users; public UsersService(IUnitOfWork uow) { _uow = uow; _users = _uow.Set<User>(); } public Task<User> FindUserAsync(int userId) { return _users.FindAsync(userId); } } }
در این قسمت به نحوهی تبدیل سورس به یک فایل قابل انتشار میپردازیم. کد زیر را به عنوان مثال در نظر بگیرید:
public sealed class Program { public static void Main() { System.Console.WriteLine("Hi"); } }
csc.exe /out:Program.exe /t:exe /r:MSCorLib.dll Program.cs
mscorlib یک فایل سورس است که شامل همهی نوعها، از قبیل int,string,byte و خیلی از نوعهای دیگر میشود. از آنجائیکه استفادهی از این نوعها به طور مکرر توسط برنامه نویسها صورت میگیرد، کمپایلر به طور خودکار این کتابخانه را به لیست ارجاعات اضافه میکند. به بیان دیگر خط بالا به شکل زیر هم قابل اجراست:
csc.exe /out:Program.exe /t:exe Program.cs
به علاوه از آنجایی که بقیهی سوئیچها هم مقدار پیش فرضی را دارند، خط زیر هم معادل خطوط بالاست:
csc.exe Program.cs
اگر به هر دلیلی دوست ندارید که سمت mscorlib ارجاعی صورت بگیرید، میتوانید از دستور زیر استفاده کنید:
/nostdlib
csc.exe /out:Program.exe /t:exe /nostdlib Program.cs
//CUI /t:exe //GUI /t:winexe //Winsows store App /t:appcontainerexe
/out:MyProject.exe /target:winexe
و برای در نظر گرفتن این سوئیچها فایل پاسخگو را به کامپایلر معرفی میکنیم:
csc.exe @MyProject.rsp CodeFile1.cs CodeFile2.cs
در صورتیکه چندین فایل پاسخگو که به آن فایلهای محلی local میگویند، معرفی کنید که دستورات آنها(سوئیچ) با دستورات داخل csc.rsp مقدار متفاوتی داشته باشند، فایلهای محلی الویت بالاتری نسبت به فایل global داشته و تنظمیات آنها روی فایل global رونوشت میگردند.
موقعیکه شما دات نت فریمورک را نصب میکنید، فایل csc.rsp را با تنظیمات پیش فرض در مسیر زیر نصب میکند:
%SystemRoot%\ Microsoft.NET\Framework(64)\vX.X.X
حروف x نمایانگر نسخهی دات نت فریمورکی هست که شما نصب کردهاید. آخرین ورژن از این فایل در زمان نگارش کتاب، شامل سوئیچهای زیر بوده است.
# This file contains commandline options that the C# # command line compiler (CSC) will process as part # of every compilation, unless the "/noconfig" option # is specified. # Reference the common Framework libraries /r:Accessibility.dll /r:Microsoft.CSharp.dll /r:System.Configuration.dll /r:System.Configuration.Install.dll /r:System.Core.dll /r:System.Data.dll /r:System.Data.DataSetExtensions.dll /r:System.Data.Linq.dll /r:System.Data.OracleClient.dll /r:System.Deployment.dll /r:System.Design.dll /r:System.DirectoryServices.dll /r:System.dll /r:System.Drawing.Design.dll /r:System.Drawing.dll /r:System.EnterpriseServices.dll /r:System.Management.dll /r:System.Messaging.dll /r:System.Runtime.Remoting.dll /r:System.Runtime.Serialization.dll /r:System.Runtime.Serialization.Formatters.Soap.dll /r:System.Security.dll /r:System.ServiceModel.dll /r:System.ServiceModel.Web.dll /r:System.ServiceProcess.dll /r:System.Transactions.dll /r:System.Web.dll /r:System.Web.Extensions.Design.dll /r:System.Web.Extensions.dll /r:System.Web.Mobile.dll /r:System.Web.RegularExpressions.dll /r:System.Web.Services.dll /r:System.Windows.Forms.Dll /r:System.Workflow.Activities.dll /r:System.Workflow.ComponentModel.dll /r:System.Workflow.Runtime.dll /r:System.Xml.dll /r:System.Xml.Linq.dll
البته ارجاع کردن به این اسمبلیها تا حد کمی باعث کند شدن صورت کامپایل میشوند؛ ولی تاثیری بر فایل نهایی و نحوهی اجرای آن نمیگذارند.
نکته: در صورتی که قصد ارجاعی را دارید، میتوانید آدرس مستقیم اسمبلی را هم ذکر کنید. ولی اگر تنها به نام اسمبلی اکتفا کنید، مسیرهای زیر جهت یافتن اسمبلی بررسی خواهند شد:
- دایرکتوری برنامه
- دایرکتوری که شامل فایل csc.exe میشود. که خود فایل mscorlib از همانجا خوانده میشود و مسیر آن شبیه مسیر زیر است:
%SystemRoot%\Microsoft.NET\Framework\v4.0.#####
- هر دایرکتوری که توسط سوئیچ lib/ مشخص شده باشد.
- هر دایرکتوری که توسط متغیر محلی lib مشخص شده باشد.
خوب، تا اینجا ممکن است مشکلی به نظر نرسد و هدف از کش کردن اطلاعات یک اکشن متد نیز همین مورد است. اما اگر این اکشن متد کش شده، به اشتباه در یک کنترلر مزین شده با ویژگی Authorize قرار گیرد، چه خواهد شد؟ مثلا این کنترلر امن، برای ارائه فایلها یا حتی نمایش قسمتی از صفحه یا کل صفحه، از کش استفاده کرده است. در بار اول دریافت فایل، بدیهی است که تمام مسایل اعتبارسنجی باید مطابق طول عمر یک کنترلر روی دهند. اما در بار دوم فراخوانی آدرس دریافت صفحه یا فایل، اصلا کار به فراخوانی کنترلر نمیرسد. به عبارتی کلیه کاربران سایت (اعم از لاگین شده، نشده، دارای دسترسی مشاهده صفحه یا آدرس امن و یا بدون دسترسی)، به این محتوای خاص بدون مشکلی دسترسی خواهند داشت (فقط کافی است که از آدرس نهایی به نحوی مطلع شوند).
سؤال: چگونه میتوان کلیه اکشن متدهای یک پروژه ASP.NET MVC را که دارای ویژگی OutputCache در یک کنترلر امن هستند، یافت؟
using System; using System.Linq; using System.Reflection; // Add a ref. to \Program Files\Microsoft ASP.NET\ASP.NET MVC 4\Assemblies\System.Web.Mvc.dll using System.Web.Mvc; // Add a ref. to System.Web using System.Web.UI; namespace FindOutputCaches { class Program { static void Main(string[] args) { var path = @"D:\site\bin\Web.dll"; var asmTarget = Assembly.LoadFrom(path); checkSecuredControllers(asmTarget); Console.WriteLine("Press a key..."); Console.Read(); } private static void checkSecuredControllers(Assembly asmTarget) { // یافتن کلیه کنترلرهایی که فیلتر اوتورایز دارند var securedControllers = asmTarget.GetTypes() .Where(type => typeof(IController).IsAssignableFrom(type) && Attribute.IsDefined(type, typeof(AuthorizeAttribute)) && !type.Name.StartsWith("T4MVC")) .ToList(); foreach (var controller in securedControllers) { // یافتن کلیه اکشن متدهای کنترلر جاری var actionMethods = controller.GetMethods(BindingFlags.Public | BindingFlags.Instance | BindingFlags.DeclaredOnly) .Where(method => typeof(ActionResult).IsAssignableFrom(method.ReturnType)) .ToList(); foreach (var method in actionMethods) { // یافتن متدهایی که دارای آوت پوت کش هستند var attributes = method.GetCustomAttributes(typeof(OutputCacheAttribute), true); if (attributes == null || !attributes.Any()) continue; var outputCache = (OutputCacheAttribute)attributes[0]; // AllowMultiple = false if (outputCache.Location == OutputCacheLocation.None) continue; //سبب عدم کش شدن شده است؛ مثلا برای کارهای ایجکسی Console.WriteLine("Detected incorrect usage of OutputCache in:\n {0}-->{1}", controller.FullName, method.Name); } } } } }
ابتدا مسیر اسمبلی کامپایل شده پروژه ASP.NET MVC که حاوی کنترلرهای برنامه است، باید مشخص گردد.
سپس در این اسمبلی کلیه نوعهای تعریف شده، یافت گردیده و آنهایی که پیاده سازی کننده IController هستند (یعنی کلاسهای کنترلر واقعی برنامه) و همچنین دارای ویژگی AuthorizeAttribute نیز میباشند، جدا خواهند شد.
در ادامه، در هر کنترلر امن یافت شده، متدهایی را بررسی خواهیم کرد که دارای خروجی از نوع ActionResult باشند (فقط اکشن متدها مدنظر هستند). اگر این اکشن متد یافت شده دارای ویژگی OutputCacheAttribute بود و همچنین Location آن به None تنظیم نشده بود ... یعنی مشکل امنیتی وجود دارد که باید برطرف شود.
البته برای تکمیل این مطلب باید دو حالت زیر هم پیاده سازی و بررسی شوند:
- کلیه Viewهای برنامه بررسی شوند. اگر در View خاصی که متعلق است به یک کنترلر یا حتی اکشن متد امن، ارجاعی به اکشن متدی کش شده در کنترلری دیگر وجود داشت، این مورد هم یک باگ امنیتی است.
- کلیه کنترلرهای عمومی که دارای اکشن متدی امن هستند نیز باید جهت یافتن OutputCache بررسی شوند.
در بسیاری از پروژههای دات نت، نیاز به استفاده از فایلهای نرم افزار آفیس، از قبیل ورد و اکسل و ... وجود دارد. برای مثال گاهی لازم است اطلاعات یک گرید، یا هر منبع دادهای، در قالب اکسل به کاربر نمایش داده شود. بدین شکل که این فایلها در زمان اجرا ساخته شده و به کاربر نمایش داده شود .حال فرض کنید شما روی سیستم خودتان Office2007 را نصب کرده اید و به اسمبلیهای این ورژن دسترسی دارید. البته بدون نیاز به نصب آفیس نیز میتوان به این توابع دسترسی داشت و از آنها در برنامه استفاده کرد که همان استفاده از Primary Interop Assemblies میباشد. مشکلی که ممکن است پیش آید این است که در کامپیوترهای کاربران ممکن است ورژنهای مختلفی از آفیس نصب باشد مانند 2003 -2007-2010-2013 و اگر با ورژن اسمبلیهایی که فراخوانیهای فایلهای اکسل از طریق آن انجام شده باشد متفاوت باشد، برنامه اجرا نمیشود .
در حالت معمول برای نمایش یک فایل آفیس مثل اکسل در برنامه، ابتدا اسمبلی مربوطه را (اکسل در این مثال) که به نام Microsoft.Office.Interop.Excel میباشد به اسمبلیهای برنامه اضافه کرده (از طریق add reference) و برای نمایش یک فایل اکسل در زمان اجرا از کدهای زیر استفاده مینماییم :
try { var application = (Microsoft.Office.Interop.Excel.Application)Activator.CreateInstance(Type.GetTypeFromProgID("Excel.Application")); Workbook wrkBook; var wbk = application.Workbooks; wrkBook = wbk.Add(); wrkBook.Activate(); application.Visible = true; } catch (Exception ex) { Error(ex.Message); }
حال اگر آفیس 2010 به عنوان مثال در سیستم ما نصب باشد، ورژن این اسمبلی 14 میباشد و اگر این برنامه را در کامپیوتر کلاینتی که آفیس 2007 بر روی آن نصب باشد انتشار دهیم اجرا نمیشود. برای حل این مشکل بنده با استفاده از روش dynamic این موضوع را حل کردم و بنظر میرسد راههای دیگری نیز برای حل آن وجود داشته باشد.
در این روش با توجه به ورژن آفیسی که بر روی سیستم کاربر نصب شده اسمبلی مربوطه را از سیستم کاربر لود کرده و فایلهای آفیس را اجرا مینماییم. در ابتدا تشخیص میدهیم چه ورژنی از آفیس بر روی سیستم کاربر نصب است :
string strVersion = null; dynamic objEApp =Activator.CreateInstance(Type.GetTypeFromProgID("Excel.Application")); if (objEApp.Version == "12.0") { strVersion = "2007"; } else if (objEApp.Version == "14.0") { strVersion = "2010"; }
روش دیگر برای انجام اینکار استفاده از اطلاعات رجیستری ویندوز است :
string strEVersionSubKey = "\\Excel.Application\\CurVer"; string strValue = null; //Value Present In Above Key string strVersion = null; //Determines Excel Version RegistryKey rkVersion = null; //Registry Key To Determine Excel Version rkVersion = Registry.ClassesRoot.OpenSubKey(strEVersionSubKey, false); //Open Registry Key if ((rkVersion != null)) //If Key Exists { strValue = (string)rkVersion.GetValue(string.Empty); //Get Value strValue = strValue.Substring(strValue.LastIndexOf(".") + 1); //Store Value switch (strValue) //Determine Version { case "11": strVersion = "2003"; break; case "12": strVersion = "2007"; break; case "14": strVersion = "2010"; break; }
if (strVersion == "2007") { string strAssemblyOff2007 = "Microsoft.Office.Interop.Excel, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"; try { Assembly xslExcelAssembly = Assembly.Load(strAssemblyOff2007); //Load Assembly Type type = xslExcelAssembly.GetTypes().Single(t => t.Name == "ApplicationClass"); dynamic application = Activator.CreateInstance(type); var workbooks = application.Workbooks; var workbook = workbooks.Add(); var worksheet = workbook.Worksheets[1]; workbook.Activate(); application.Visible = true; } catch (Exception ex) { } }
برای اضافه کردن یک فایل به عنوان منبع، از سوئیچ [embed[resource استفاده میشود. این سوئیچ محتوای هر نوع فایلی را که به آن پاس شود، به فایل PE اجرایی انتقال داده و جدول ManifestResourceDef را به روز میکند تا سیستم از وجود آن آگاه شود.
سوئیچ [link[Resource هم برای الحاق کردن یک فایل به اسمبلی به کار میرود و دو جدول ManifestResourceDef و FileDef را جهت معرفی منبع جدید و شناسایی فایل اسمبلی که حاوی این منبع است، به روز میکند. در این حالت فایل منبع embed نشده و باید در کنار پروژه منتشر شود.
csc هم قابلیتهای مشابهی را با استفاده از سوئیچهای resource/ و link/ دارد و به روز رسانی و دیگر اطلاعات تکمیلی آن مشابه موارد بالاست.
شما حتی میتوانید منابع یک فایل win32 را خیلی راحت و آسان به اسمبلی معرفی کنید. شما به آسانی میتوانید مسیر یک فایل res. را با استفاده از سوئیچ win32res/ در al یا csc مشخص کنید. یا برای embed کردن آیکن یک برنامه win32 از سوئیچ win32icon/ مسیر یک فایل ICO را مشخص کنید. در ویژوال استودیو اینکار به صورت ویژوالی در پنجره تنظمیات پروژه و برگهی Application امکان پذیر است. دلیل اصلی که آیکن برنامهها به صورت embed ذخیره میشوند این است که این آیکن برای فایل اجرایی یک برنامهی مدیریت شده هم به کار میرود.
فایلهای اسمبلی Win32 شامل یک فایل مانیفست اطلاعاتی هستند که به طور خودکار توسط کمپایلر سی شارپ تولید میگردند. با استفاده از سوئیچ nowin32manifest/ میتوان از ایجاد این نوع فایل جلوگیری کرد. این اطلاعات به طور پیش فرض شبیه زیر است:
<?xml version="1.0" encoding="UTF8" standalone="yes"?> <assembly xmlns="urn:schemasmicrosoftcom:asm.v1" manifestVersion="1.0"> <assemblyIdentity version="1.0.0.0" name="MyApplication.app" /> <trustInfo xmlns="urn:schemasmicrosoftcom:asm.v2"> <security> <requestedPrivileges xmlns="urn:schemasmicrosoftcom:asm.v3"> <requestedExecutionLevel level="asInvoker" uiAccess="false"/> </requestedPrivileges> </security> </trustInfo> </assembly>
موقعیکه شما یک اسمبلی میسازید باید فیلدهای منبع نسخه بندی را هم ذکر کنید. اینکار توسط خصوصیتها (Attributes) در سطح کد انجام میگیرد. این خصوصیات شامل موارد زیر هستند که در فضای نام Reflection قرار گرفتهاند.
using System.Reflection; // FileDescription version information: [assembly: AssemblyTitle("MultiFileLibrary.dll")] // Comments version information: [assembly: AssemblyDescription("This assembly contains MultiFileLibrary's types")] // CompanyName version information: [assembly: AssemblyCompany("Wintellect")] // ProductName version information: [assembly: AssemblyProduct("Wintellect (R) MultiFileLibrary's Type Library")] // LegalCopyright version information: [assembly: AssemblyCopyright("Copyright (c) Wintellect 2013")] // LegalTrademarks version information: [assembly:AssemblyTrademark("MultiFileLibrary is a registered trademark of Wintellect")] // AssemblyVersion version information: [assembly: AssemblyVersion("3.0.0.0")] // FILEVERSION/FileVersion version information: [assembly: AssemblyFileVersion("1.0.0.0")] // PRODUCTVERSION/ProductVersion version information: [assembly: AssemblyInformationalVersion("2.0.0.0")] // Set the Language field (discussed later in the "Culture" section) [assembly:AssemblyCulture("")]
جدول زیر اطلاعاتی در مورد سوئیچهای AL جهت مقداردهی این فیلدهای نسخه بندی دارد (کامپایلر سی شارپ این سوئیچها را ندارد و بهتر است از طریق همان خصوصیات در کدها اقدام کنید). بعضی از اطلاعات زیر با استفاده از سوئیچها قابل تغییر نیستند؛ چرا که این مقادیر یا ثابت هستند یا اینکه طبق شرایطی از بین چند مقدار ثابت، یکی از آنها انتخاب میشود.
نسخه منبع | سوئیچ AL.exe | توصیف خصوصیت یا سوئیچ مربوطه |
FILEVERSION | fileversion/ | System.Reflection.AssemblyFileVersionAttribute. |
PRODUCTVERSION | productversion/ | System.Reflection. AssemblyInformationalVersionAttribute |
FILEFLAGSMASK | - | Always set to VS_FFI_FILEFLAGSMASK (defined in WinVer.h as 0x0000003F). |
FILEFLAGS | - | همیشه صفر است |
FILEOS | - | در حال حاضر همیشه VOS__WINDOWS32 است |
FILETYPE | target/ | Set to VFT_APP if /target:exe or /target:winexe is specified; set to VFT_DLL if /target:library is specified. |
FILESUBTYPE | - | Always set to VFT2_UNKNOWN. (This field has no meaning for VFT_APP and VFT_DLL.) |
AssemblyVersion | version/ | System.Reflection.AssemblyVersionAttribute |
Comments | description/ | System.Reflection.AssemblyDescriptionAttribute |
CompanyName | company/ | System.Reflection.AssemblyCompanyAttribute |
FileDescription | title/ | System.Reflection.AssemblyTitleAttribute |
FileVersion | version/ | System.Reflection.AssemblyFileVersionAttribute |
InternalName | out/ | ذکر نام فایل خروجی بدون پسوند. |
LegalCopyright | copyright/ | System.Reflection.AssemblyCopyrightAttribute |
LegalTrademarks | trademark/ | System.Reflection.AssemblyTrademarkAttribute |
OriginalFilename | out | ذکر نام فایل خروجی بدون پسوند. |
PrivateBuild | - | همیشه خالی است. |
ProductName | product | System.Reflection.AssemblyProductAttribute |
ProductVersion | productversion | System.Reflection. AssemblyInformationalVersionAttribute |
SpecialBuild | - | همیشه خالی است. |
شما برای ویرایش این فایل میتوانید به راحتی آن را باز کرده و اطلاعات داخل آن را تغییر دهید. ویژوال استودیو نیز برای ویرایش این فایل، امکانات GUI را نیز فراهم کرده است. برای استفاده از این امکان، پنجرهی properties را در سطح Solution باز کرده و در تب Application روی Assembly Information کلیک کنید.