একটি মেটাপ্যাকেজের উপর নির্ভর করে নেটস্ট্যান্ডার্ড লাইব্রেরির অ্যাপ্লিকেশনটির কী কী প্রভাব রয়েছে?

Question

ধরুন আমার কাছে একটি ক্লাস লাইব্রেরি রয়েছে যা আমি নেটস্ট্যান্ডার্ড ১.৩ লক্ষ্য করতে চাইছি, তবে এটিও ব্যবহার করব BigInteger। এখানে একটি তুচ্ছ উদাহরণ - একমাত্র উত্স ফাইলটি হ'ল Adder.cs:

using System;
using System.Numerics;

namespace Calculator
{
    public class Adder
    {
        public static BigInteger Add(int x, int y)
            => new BigInteger(x) + new BigInteger(y);            
    }
}

এর জগতে ফিরে project.json, আমি বিভাগটিতে লক্ষ্যবস্তু করব netstandard1.3এবং উদাহরণস্বরূপ সংস্করণ 4.0.1 এর frameworksউপর একটি সুস্পষ্ট নির্ভরতা রাখব have System.Runtime.Numericsআমি তৈরি করা নুগেট প্যাকেজটি কেবল সেই নির্ভরতার তালিকা করবে।

সিএসপি্রোজ-ভিত্তিক ডটনেট টুলিংয়ের সাহসী নতুন জগতে (আমি কমান্ড-লাইন সরঞ্জামগুলির v1.0.1 ব্যবহার করছি) লক্ষ্য করার সময় একটি অন্তর্নিহিত মেটাপ্যাকেজ প্যাকেজ রেফারেন্স রয়েছে । এর অর্থ হল যে আমার প্রকল্পের ফাইলটি আসলেই ছোট, কারণ এর সুস্পষ্ট নির্ভরতার প্রয়োজন নেই:NETStandard.Library 1.6.1netstandard1.3

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netstandard1.3</TargetFramework>
  </PropertyGroup>
</Project>

... তবে উত্পাদিত নুগেট প্যাকেজের উপর নির্ভরতা রয়েছে NETStandard.Library, যা পরামর্শ দেয় যে আমার ছোট লাইব্রেরিটি ব্যবহার করতে আপনার সেখানে সমস্ত কিছু প্রয়োজন ।

দেখা যাচ্ছে যে ব্যবহার করে আমি সেই কার্যকারিতাটি অক্ষম করতে পারি DisableImplicitFrameworkReferences, তারপরে পুনরায় নির্ভরতার সাথে যুক্ত করুন:

<Project Sdk="Microsoft.NET.Sdk">    
  <PropertyGroup>
    <TargetFramework>netstandard1.3</TargetFramework>
    <DisableImplicitFrameworkReferences>true</DisableImplicitFrameworkReferences>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="System.Runtime.Numerics" Version="4.0.1" />
  </ItemGroup>    
</Project>

এখন আমার নিউগেট প্যাকেজটি ঠিক এর উপর নির্ভর করে। স্বজ্ঞাতভাবে, এটি "পাতলা" প্যাকেজের মতো অনুভব করে।

তাহলে আমার গ্রন্থাগারের কোনও গ্রাহকের জন্য সঠিক পার্থক্য কী? যদি কেউ এটি ইউডাব্লুপি অ্যাপ্লিকেশনটিতে ব্যবহার করার চেষ্টা করে, তবে দ্বিতীয়, "ছাঁটাই" নির্ভরতার ফর্মটি বোঝায় যে ফলাফলটি আরও কম হবে?

DisableImplicitFrameworkReferencesস্পষ্ট করে ডকুমেন্ট না করে (যতদূর আমি দেখেছি; একটি ইস্যুতে আমি এটি সম্পর্কে পড়েছি ) এবং কোনও প্রকল্প তৈরি করার সময় অন্তর্নিহিত নির্ভরতা ডিফল্ট করে, মাইক্রোসফ্ট ব্যবহারকারীদের কেবলমাত্র মেটাপ্যাকেজের উপর নির্ভর করতে উত্সাহিত করে - তবে আমি কীভাবে হতে পারি আমি যখন ক্লাস লাইব্রেরি প্যাকেজ তৈরি করছি তখন এর অসুবিধাগুলি নিশ্চিত না?

Comments

এটি লক্ষ্য করা উচিত যে নির্ভরতা ট্রিমিংয়ের কাজ চলছে । বর্তমানে, Hello World!স্ব-অন্তর্ভুক্ত অ্যাপ্লিকেশনটির আকার <10MB এ হ্রাস পেয়েছে।

— আবর্নি

ক্লাসিক। নেট ফ্রেমওয়ার্ক সি # হ্যালো-ওয়ার্ল্ড প্রকল্পের < 20KB আকারের তুলনায় @ বারবারি 10 এমবি এখনও অনেক বেশি ।

— দাই

Answer 1

অতীতে, আমরা বিকাশকারীদের NETStandard.Libraryনুগেট প্যাকেজগুলি থেকে মেটা প্যাকেজ ( ) উল্লেখ না করার পরিবর্তে পৃথক প্যাকেজ, যেমন System.Runtimeএবং এর জন্য রেফারেন্স দেওয়ার পরামর্শ দিয়েছি System.Collections। যুক্তিটি হ'ল আমরা মেটা প্যাকেজটিকে একটি গুচ্ছ প্যাকেজগুলির শর্টহ্যান্ড হিসাবে ভেবেছিলাম যা নেট নেট প্ল্যাটফর্মের আসল পারমাণবিক বিল্ডিং ব্লক ছিল। অনুমানটি হ'ল: আমরা হয়ত অন্য একটি নেট নেট প্ল্যাটফর্ম তৈরি করে যা কেবলমাত্র এই কয়েকটি পারমাণবিক ব্লককে সমর্থন করে তবে সেগুলি সবগুলিই নয়। অতএব, আপনি যত কম প্যাকেজ উল্লেখ করেছেন, তত বেশি পোর্টেবল আপনি হবেন। আমাদের সরঞ্জামটি কীভাবে বৃহত প্যাকেজ গ্রাফগুলির সাথে ডিল করে তা নিয়েও উদ্বেগ ছিল।

এগিয়ে চলুন, আমরা এটিকে সহজ করব:

1. .NET স্ট্যান্ডার্ড একটি পারমাণবিক বিল্ডিং ব্লক । অন্য কথায়, নতুন প্ল্যাটফর্মগুলিকে .NET স্ট্যান্ডার্ড সাবসেট করার অনুমতি নেই - তাদের এগুলি সব প্রয়োগ করতে হবে।

2. আমরা NET স্ট্যান্ডার্ড সহ আমাদের প্ল্যাটফর্মগুলি বর্ণনা করতে প্যাকেজগুলি ব্যবহার করা থেকে দূরে চলেছি।

এর অর্থ, আপনাকে .NET স্ট্যান্ডার্ডের জন্য কোনও নিউগেট প্যাকেজ উল্লেখ করতে হবে না। আপনি lib ফোল্ডারের সাথে আপনার নির্ভরতা প্রকাশ করেছেন, ঠিক যেমন এটি অন্যান্য সমস্ত নেট নেট প্ল্যাটফর্মগুলির জন্য কাজ করেছে, বিশেষত। নেট ফ্রেমওয়ার্ক।

যাইহোক, এই মুহুর্তে আমাদের সরঞ্জামগুলি এখনও রেফারেন্সে জ্বলবে NETStandard.Library। এটির কোনও ক্ষতি নেই, এটি কেবল এগিয়ে যাওয়া অপ্রয়োজনীয় হয়ে উঠবে।

আমি এই প্রশ্নটি অন্তর্ভুক্ত করতে .NET স্ট্যান্ডার্ড রেপো এ FAQ আপডেট করব ।

আপডেট : এই প্রশ্নটি এখন FAQ এর অংশ ।

Comments

ধন্যবাদ - এটি অনেক অর্থবোধ করে। আমি মনে করি যে আমি আংশিক বিভ্রান্ত ছিলাম কারণ প্রকল্প.জসন জগতে প্যাকেজগুলি যখন লক্ষ্যবস্তু করা হয়েছিল সেই কাঠামোর যুক্তিযুক্ত অংশ ছিল তখনও আমাকে নির্ভরতা যুক্ত করতে হয়েছিল (যেমন: সিস্টেম.আরটাইম।সংখ্যা নেটস স্ট্যান্ডার্ড ১.৩ এর জন্য) - সুতরাং আমি ভেবেছিলাম এনইটিএস স্ট্যান্ডার্ড। লাইব্রেরি ছিল সত্যিই নির্ভরতা হিসাবে তাদের টান।

— জন স্কিটি

বোমার আমি প্যাকেজগুলি রেফারেন্স করার ধারণাটি পছন্দ করেছি, কারণ মনে হয়েছিল পুরো "রান্নাঘরের সিঙ্ক" এর পরিবর্তে আমি কেবল যা চাই তা কেবল উল্লেখ করতে পারি। আমি সম্ভবত এটি সম্পর্কে সঠিকভাবে চিন্তা করছি না?

— নাট বার্বেটিনি

আপনি অগত্যা এটিকে ভুল পদ্ধতিতে ভাবছেন না, তবে আপনি কেন যত্ন করছেন তা প্রশ্ন is প্ল্যাটফর্মটি অসীমভাবে কম্পোজেবল নয় তা বোঝা গুরুত্বপূর্ণ। আপনি যখন একটি ভাগ করা কাঠামো পরিবেশে চালনা করেন (। নেট ফ্রেমওয়ার্ক, মনো,। নেট কোর) এই সমস্ত বিট যে কোনও উপায়ে উপস্থিত থাকে। যদি আপনি একটি স্ব-অন্তর্ভুক্ত অ্যাপ্লিকেশনটি তৈরি করেন (লিঙ্কারের সাথে জ্যামারিন, মনো / .NET কোর) আমরা আপনার প্রকৃত ব্যবহারের ভিত্তিতে স্বয়ংক্রিয়ভাবে ট্রিম করতে পারি। সুতরাং যে কোনও উপায়ে আপনি ছোট ব্লকগুলি উল্লেখ না করে কোনও কিছু হারাচ্ছেন না।

— ইমো ল্যান্ডওয়ার্থ

এই প্যাকেজটিকে অনুমতি না দিয়ে কোনও যৌক্তিক কোনও ব্যবসায়িক লজিক প্রকল্পে কোনও HTTP অনুরোধ করা থেকে কোনও বিকাশকারীকে বাধা দেওয়ার মতো বিধিগুলি কার্যকর করার বিষয়ে কী আছে?

— ডেভিড ফেরেটি

অগত্যা নয়, তবে আপনি কীভাবে এটি প্রয়োগ করেন, অর্থাত্ কোনও বিকাশকারীকে রেফারেন্স যুক্ত করা থেকে বিরত করে? আমি এমন একটি বিশ্লেষক লিখতাম যা স্তরের নিয়মগুলি প্রয়োগের জন্য বিল্ড সময়ে ইনজেক্ট করা হয় এবং বিল্ড মেশিনে ত্রুটি সৃষ্টি করে।

— ইমো ল্যান্ডওয়ার্থ

Answer 2

দলটি পাতলা প্যাকেজ সেটটি কী তা নির্ধারণের জন্য সুপারিশ করত। তারা আর এটি করে না, এবং লোকেরা কেবল NETS স্ট্যান্ডার্ডকেই আনার পরামর্শ দেয় L লাইব্রেরির পরিবর্তে (এসডিকে-স্টাইল প্রকল্পের ক্ষেত্রে এটি আপনার জন্য স্বয়ংক্রিয়ভাবে সম্পন্ন হবে)।

কেন এটি ছিল এ সম্পর্কে আমি পুরোপুরি সরাসরি অগ্রিম উত্তর কখনই পাইনি, তাই আমাকে কিছু শিক্ষিত অনুমান করার অনুমতি দিন।

প্রাথমিক কারণ সম্ভবত এটি হতে পারে যে তাদের নির্ভর করে গ্রন্থাগারের সংস্করণগুলির পার্থক্যগুলি লুকানোর অনুমতি দেয় যা লক্ষ্য ফ্রেমওয়ার্কগুলি পরিবর্তন করার সময় আপনাকে অন্যথায় নিজেকে ট্র্যাক করতে হবে। এটি SDK- ভিত্তিক প্রজেক্ট ফাইলগুলির সাথে আরও অনেক বেশি ব্যবহারকারী বান্ধব সিস্টেম, কারণ প্ল্যাটফর্মটির শালীন অংশ পেতে আপনার খোলামেলাভাবে কোনও রেফারেন্সের প্রয়োজন নেই (ঠিক যেমন আপনি ডেস্কটপ-ল্যান্ডে বিশেষত mscorlib এর ডিফল্ট রেফারেন্সগুলি ব্যবহার করতেন) )।

netstandardগ্রন্থাগার হওয়ার অর্থ কী , বা netcoreappউপযুক্ত নুগেট প্যাকেজে অ্যাপ্লিকেশন হওয়ার অর্থ কী তা বোঝাতে, তাদের ভিজুয়াল স্টুডিও (বা dotnet new) যেমন দেখায় সেগুলির সংজ্ঞাটিতে কোনও বিশেষ জ্ঞান গড়ে তুলতে হবে না ।

প্রেরিত ডিএলএল সীমাবদ্ধ করার জন্য প্রকাশের সময় স্থির বিশ্লেষণ ব্যবহার করা যেতে পারে, যা ইউডাব্লুপি-র জন্য দেশীয় সংকলন করার সময় তারা আজ কিছু করেন (কিছু সতর্ক থাকা সত্ত্বেও)। তারা আজ নেট কোরের জন্য এটি করে না, তবে আমি মনে করি এটি একটি অপ্টিমাইজেশন যা তারা বিবেচনা করেছে (পাশাপাশি নেটিভ কোড সমর্থন করে)।

আপনাকে খুব বেছে বেছে বেছে নেওয়া থেকে বিরত করার কিছুই নেই, যদি আপনি এটি চয়ন করেন। আমি বিশ্বাস করি আপনি বুঝতে পারবেন, আপনি প্রায় শুধুমাত্র এক এরকম, যা উদ্দেশ্য (যেহেতু সবাই আনছে অধিকৃত হবে পরাজিত হন NETStandard.Libraryবা Microsoft.NETCore.App)।

Comments

আমি একমত যে একবারে যদি একের বেশি নির্ভরতা হয় তবে যদি তাদের মধ্যে কেউ এনে দেয় তবে অবশ্যই উদ্দেশ্যটি হ্রাস পাবে NETStandard.Library। এটি কিছুটা স্বতঃসিদ্ধ অবশ্যই, ... যদি আমিNETStandard.Library নোডা সময়ের উপর নির্ভর করি তবে এর অর্থ নোদা সময়ের শীর্ষে নির্মিত অন্য কোনও গ্রন্থাগারের নির্ভরতা ছাঁটাই করার কোনও কারণ নেই, ইত্যাদি এখনকার জন্য এটি নির্বাচনী হওয়ার লোভনীয় (নোডা টাইম হ'ল ২.০-এর দিকে যাচ্ছেন) তারপর একবার কনভেনশন প্রতিষ্ঠিত হওয়ার পরে কিছুটা বিশ্রাম করুন - সিলেক্টিক থেকে লাইব-বেসডে পরিবর্তন করা একটি অ-ব্রেকিং পরিবর্তন হবে, আমি ধরে নিলাম, তবে বিপরীতটি সত্য নয়।

— জন স্কিটি

Answer 3

আপনার অন্তর্নিহিত রেফারেন্সটি অক্ষম করার দরকার নেই। লাইব্রেরিটি যে সমস্ত প্ল্যাটফর্মগুলি চালাতে সক্ষম হবে সেগুলির ইতিমধ্যে সংস্থাগুলি থাকবে যেগুলি NETStandard.Libraryনির্ভরতার প্রয়োজন।

.NET স্ট্যান্ডার্ড লাইব্রেরি হল একটি স্পেসিফিকেশন, রেফারেন্স অ্যাসেমব্লির একটি সেট যা আপনি তার বিপরীতে সংকলন করেন এমন একটি APIs এর সেট সরবরাহ করে যা প্ল্যাটফর্মগুলির জেনে সেট এবং প্ল্যাটফর্মের সংস্করণগুলির যেমন জেনে গ্যারান্টিযুক্ত, যেমন নেট নেট বা। নেট ফ্রেমওয়ার্ক । সংকলককে সফলভাবে আপনার কোডটি তৈরি করতে অনুমতি দেওয়ার জন্য এটি কেবলমাত্র এপিআই আকারের এপিআই আকার নয়।

এই API গুলি বাস্তবায়ন একটি লক্ষ্য প্ল্যাটফর্ম দ্বারা সরবরাহ করা হয়, যেমন। নেট কোর, মনো বা। নেট ফ্রেমওয়ার্ক। তারা প্ল্যাটফর্মের সাথে চালনা করে, কারণ এগুলি প্ল্যাটফর্মের একটি প্রয়োজনীয় অংশ। সুতরাং একটি ছোট নির্ভরতা সেট নির্দিষ্ট করার প্রয়োজন নেই - সবকিছু ইতিমধ্যে রয়েছে, আপনি এটি পরিবর্তন করবেন না।

NETStandard.Libraryপ্যাকেজ এই রেফারেন্স সমাহারগুলি প্রদান করে। বিভ্রান্তির এক বিন্দু হ'ল সংস্করণ নম্বর - প্যাকেজটি সংস্করণ 1.6.1, তবে এর অর্থ "। নেট স্ট্যান্ডার্ড 1.6" নয়। এটি কেবল প্যাকেজের সংস্করণ।

আপনি টার্গেট করছেন .NET স্ট্যান্ডার্ডের সংস্করণটি আপনার প্রকল্পে নির্দিষ্ট লক্ষ্য ফ্রেমওয়ার্ক থেকে আসে।

যদি আপনি একটি লাইব্রেরি তৈরি করে থাকেন এবং এটি নেট। স্ট্যান্ডার্ড 1.3 চালু রাখতে চান তবে আপনি NETStandard.Libraryবর্তমানে প্যাকেজটি উল্লেখ করতে পারেন , বর্তমানে সংস্করণ 1.6.1 এ। তবে আরও গুরুত্বপূর্ণ বিষয়, আপনার প্রকল্প ফাইলটি লক্ষ্যবস্তু হবে netstandard1.3।

NETStandard.Libraryপ্যাকেজ আপনি আপনার লক্ষ্য ফ্রেমওয়ার্ক অবজ্ঞাসূচক উপর নির্ভর করে রেফারেন্স সমাহারগুলি একটি ভিন্ন সেট দেব (আমি সংক্ষিপ্ততা জন্য সরল, কিন্তু মনে lib\netstandard1.0, lib\netstandard1.1এবং নির্ভরতা গ্রুপ )। সুতরাং যদি আপনার প্রকল্প টার্গেট করে তবে netstandard1.3আপনি ১.৩ রেফারেন্স অ্যাসেম্বলিগুলি পাবেন। আপনি যদি লক্ষ্যবস্তু করেন তবে আপনি netstandard1.6১.6 রেফারেন্স অ্যাসেম্বলিগুলি পাবেন।

আপনি যদি কোনও অ্যাপ্লিকেশন তৈরি করে থাকেন তবে আপনি .NET স্ট্যান্ডার্ডটিকে লক্ষ্য করতে পারবেন না। এটির কোনও অর্থ নেই - আপনি কোনও স্পেসিফিকেশন চালাতে পারবেন না। পরিবর্তে, আপনি কংক্রিট প্ল্যাটফর্মগুলি লক্ষ্যবস্তু করেন, যেমন net452বা netcoreapp1.1। নিউগেট এই প্ল্যাটফর্মগুলি এবং netstandardলক্ষ্য ফ্রেমওয়ার্ক মনিকারগুলির মধ্যে ম্যাপিংটি জানেন , তাই lib\netstandardX.Xআপনার টার্গেট প্ল্যাটফর্মের সাথে কোন ফোল্ডারগুলি উপযুক্ত compatible এটি আরও জানে যে NETStandard.Libraryটার্গেট প্ল্যাটফর্ম দ্বারা নির্ভরতাগুলি সন্তুষ্ট, সুতরাং অন্য কোনও অ্যাসেমব্লিতে টানবে না।

একইভাবে, স্ট্যান্ডেলোন .NET কোর অ্যাপ তৈরি করার সময়। নেট স্ট্যান্ডার্ড বাস্তবায়ন সমাবেশগুলি আপনার অ্যাপ্লিকেশানের সাথে অনুলিপি করা হয়। উল্লেখটি NETStandard.Libraryঅন্য কোনও নতুন অ্যাপ্লিকেশন আনবে না।

দ্রষ্টব্য যে dotnet publishএকটি স্বতন্ত্র অ্যাপ্লিকেশন তৈরি করবে , তবে এটি বর্তমানে ছাঁটাই করবে না এবং সমস্ত অ্যাসেম্বলি প্রকাশ করবে। এটি স্বয়ংক্রিয়ভাবে সরঞ্জাম দ্বারা পরিচালিত হবে , সুতরাং আবার আপনার লাইব্রেরিতে ট্রিমিং নির্ভরতা এখানে সহায়তা করবে না।

কেবলমাত্র আমি কল্পনা করতে পারি যেখানে রেফারেন্সটি সরাতে সাহায্য করতে পারে এটি NETStandard.Libraryহ'ল যদি আপনি এমন একটি প্ল্যাটফর্ম লক্ষ্য করে যা যা .NET স্ট্যান্ডার্ড সমর্থন করে না, এবং আপনি .NET স্ট্যান্ডার্ড থেকে একটি প্যাকেজ খুঁজে পেতে পারেন যেখানে সমস্ত ট্রান্সজিটিভ নির্ভরতা চলতে পারে আপনার লক্ষ্য প্ল্যাটফর্মের উপর। আমার সন্দেহ হয় যে এমন অনেকগুলি প্যাকেজ নেই যা এই বিলে মানায়।

Comments

আপনি যদি dotnet publishকোনও নির্দিষ্ট রানটাইমটি করেন তবে এটি dotnet.exe (বা এর লিনাক্স / ওএস এক্স সমতুল্য) সহ সমস্ত নির্ভরতা আনবে। এটি সেই মুহুর্তে সম্পূর্ণ একা একা মোতায়েন করা উচিত। ইউনিট পরীক্ষা প্রকল্পের ফলাফলগুলি দেখুন: gist.github.com/bradwilson/6cc5a8fdfa18230aa6c99b851fb85c01

— ব্র্যাড উইলসন

আমি মনে করি শেষ অনুচ্ছেদটি যথাযথভাবে ইস্যু ... এবং এটি যদি কোনও সমস্যা না হত তবে আমাদের নেটস স্ট্যান্ডার্ড ১.এক্সের বিভিন্ন সংস্করণ কেন প্রয়োজন হবে না? প্রত্যেক প্ল্যাটফর্ম netstandard1.6 সবকিছু থাকে, তাহলে কেন এমন আছে একটা ধারণা যেমন netstandard1.0? এটা আমার জন্য বিভ্রান্তিকর অংশ।

— জন স্কিটি 13

এবং .NET স্ট্যান্ডার্ড সমর্থন করে এমন প্ল্যাটফর্মগুলির তালিকায় বহু ইউনিটি প্ল্যাটফর্মগুলির মধ্যে কোনওটি অন্তর্ভুক্ত নয়।

— নাগরিকত্ব

(আপনার ধৈর্য অনেক প্রশংসা করা হয়, BTW আমি সত্যিই এই হবে সব জানার আশা করছি, এবং এটি অনেক অনেক বিকাশকারীদের কাছে সাহায্যের হবে ...।)

— জন স্কিট

আসুন আমরা এই আলোচনাটি আড্ডায় চলতে থাকি ।

— নাগরিকত্ব