.NET के लिए Azure SDK: एक कठिन त्रुटि खोज के बारे में कहानी

जब हमने .NET प्रोजेक्ट के लिए Azure SDK में त्रुटियों की खोज करने का निर्णय लिया, तो हम इसके आकार से सुखद आश्चर्यचकित थे। "कोड की साढ़े तीन लाख लाइनें," हम कहते रहे, परियोजना के आँकड़ों का अध्ययन। बहुत सारे निष्कर्ष हो सकते हैं। काश और अलैक! परियोजना चालाक बन गई। तो परियोजना का क्या उत्साह था और इसे कैसे जांचा गया - इस लेख में पढ़ें।

परियोजना के बारे में

मैं अपने पिछले एक के बाद यह लेख लिख रहा हूं, जो कि Microsoft Azure: Azure PowerShell: Mostly Harmless से संबंधित एक परियोजना के बारे में भी था। इसलिए, इस बार मैं विविध और दिलचस्प त्रुटियों की एक ठोस संख्या पर दांव लगा रहा था। आखिरकार, स्थैतिक विश्लेषण के संदर्भ में परियोजना का आकार एक बहुत ही महत्वपूर्ण कारक है, विशेष रूप से जब पहली बार किसी परियोजना की जांच करते हैं। वास्तव में, व्यवहार में, वन-टाइम चेक एप्लिकेशन सही दृष्टिकोण नहीं है। फिर भी, यदि डेवलपर्स इसके लिए जाते हैं, तो यह केवल विश्लेषक परिचय के चरण में होता है। एक ही समय में, कोई भी अपने बट को बड़ी संख्या में चेतावनियों को छांटने का काम नहीं करता है और बस उन्हें तकनीकी ऋण के रूप में बंद कर देता है, जो बड़े पैमाने पर चेतावनी तंत्र का उपयोग करके और उन्हें विशेष ठिकानों में संग्रहीत करता है। पहली बार एनालाइजर चलाते समय बड़ी संख्या में चेतावनी देना ठीक है। हमारे लिए, हम अनुसंधान उद्देश्यों के लिए एक बार की जाँच के लिए जाते हैं। इस कारण से, बड़े प्रोजेक्ट हमेशा छोटे लोगों की तुलना में निम्न विश्लेषण के लिए अधिक बेहतर होते हैं।

हालाँकि, .NET प्रोजेक्ट के लिए Azure SDK तुरंत एक परीक्षण योग्य बिस्तर साबित हुआ। यहां तक ​​कि इसके प्रभावशाली आकार ने भी मदद नहीं की, बल्कि इस पर काम करना जटिल हो गया। इसका कारण निम्नलिखित परियोजना के आँकड़े हैं:

• .cs स्रोत फ़ाइलें (परीक्षण सहित नहीं): 16,500
• विज़ुअल स्टूडियो सॉल्यूशंस (.sln): 163
• कोड की गैर-खाली लाइनें: 3 462 000
• इन ऑटो जनरेटेड में से: लगभग 3,300,000
• प्रोजेक्ट रिपॉजिटरी GitHub पर उपलब्ध है ।

लगभग 95% कोड स्वचालित रूप से उत्पन्न होता है, और उस कोड का बहुत बार दोहराया जाता है। स्थैतिक विश्लेषक के साथ ऐसी परियोजनाओं की जांच करना आमतौर पर समय लेने वाली और बेकार है, क्योंकि बहुत अधिक व्यावहारिक है, लेकिन अतार्किक (कम से कम पहली नज़र में) और निरर्थक कोड है। इससे बड़ी संख्या में झूठी सकारात्मकता पैदा होती है।

सभी १६३ विज़ुअल स्टूडियो समाधानों में कोड की सभी मात्रा "शीर्ष पर चेरी" बन गई। शेष कोड (ऑटो-जनरेट नहीं) की जांच करने के लिए कुछ प्रयास किए गए। क्या वास्तव में मदद की गई तथ्य यह है कि सभी ऑटो-जेनरेट किए गए कोड को समाधान उपनिर्देशिकाओं में सापेक्ष पथ "<समाधान निर्देशिका> \ src \ Generated" द्वारा संग्रहीत किया गया था। इस प्रकार की प्रत्येक .cs फ़ाइल में टैग में एक विशेष टिप्पणी है <auto-generate> :

// <auto-generated> // Copyright (c) Microsoft Corporation. All rights reserved. // Licensed under the MIT License. See License.txt in the project root for // license information. // // Code generated by Microsoft (R) AutoRest Code Generator. // Changes may cause incorrect behavior and will be lost if the code is // regenerated. // </auto-generated> 

प्रयोग की शुद्धता के लिए, मैंने पैच के बारे में दस बेतरतीब ढंग से चयनित ऑटो-जनरेट किए गए समाधानों की जाँच की। मैं परिणाम के बारे में बाद में बताऊंगा।

इसलिए, शेष "ईमानदार" कोड की छोटी राशि के बावजूद, मैं अभी भी जो कुछ भी था उससे कई त्रुटियों को खोजने में कामयाब रहा। इस बार मैं पीवीएस-स्टूडियो डायग्नोस्टिक्स के कोड्स के क्रम में चेतावनी का हवाला देने वाला नहीं हूं। इसके बजाय, मैं संदेशों को उन समाधानों पर समूहित करूँगा जिनमें वे पाए गए हैं।

खैर, आइए देखें कि मैंने .NET कोड के लिए Azure SDK में क्या पाया।

Microsoft.Azure.Management.Advisor

यह कई समाधानों में से एक है जिसमें ऑटो-जनरेट कोड होता है। जैसा कि मैंने पहले कहा था, मैंने इस तरह के एक दर्जन समाधानों के बारे में यादृच्छिक रूप से जाँच की। प्रत्येक मामले में, चेतावनी समान थी, और, उम्मीद के मुताबिक, बेकार। यहाँ कुछ उदाहरण हैं।

V3022 अभिव्यक्ति 'साख! = अशक्त' हमेशा सच है। AdvisorManagementClient.cs 204

 // Code generated by Microsoft (R) AutoRest Code Generator. .... public ServiceClientCredentials Credentials { get; private set; } .... public AdvisorManagementClient(ServiceClientCredentials credentials, params DelegatingHandler[] handlers) : this(handlers) { if (credentials == null) { throw new System.ArgumentNullException("credentials"); } Credentials = credentials; if (Credentials != null) // <= { Credentials.InitializeServiceClient(this); } } 

जाहिर है, यह कोड निरर्थक है और क्रेडेंशियल्स! = नल जाँच व्यर्थ है। फिर भी, कोड काम करता है। और स्वतः उत्पन्न होता है। इस कारण से, यहां कोई शिकायत नहीं।

V3022 अभिव्यक्ति '_queryParameters.Count> 0' हमेशा गलत है। कॉन्फ़िगरेशनऑपरेशन .cs 871

 // Code generated by Microsoft (R) AutoRest Code Generator. .... public async Task<AzureOperationResponse<IPage<ConfigData>>> ListBySubscriptionNextWithHttpMessagesAsync(....) { .... List<string> _queryParameters = new List<string>(); if (_queryParameters.Count > 0) { .... } .... } 

फिर, यह एक अतार्किक निर्माण जैसा लगता है। किसी कारण से, कोड लेखक नव निर्मित खाली सूची के आकार की जांच करते हैं। वास्तव में, यह सब सही है। इस बिंदु पर, चेक का कोई मतलब नहीं है, लेकिन अगर डेवलपर्स सूची निर्माण को जोड़ते हैं, उदाहरण के लिए, एक अन्य संग्रह के आधार पर, चेक निश्चित रूप से मूल्य-रहित होगा। फिर - कोड के लिए कोई दावा नहीं, ज़ाहिर है, इसकी उत्पत्ति के संबंध में।

प्रत्येक ऑटो-जनरेट किए गए समाधान के लिए सैकड़ों समान चेतावनी जारी की गई हैं। उनकी निरर्थकता को देखते हुए, मुझे लगता है कि ऐसे मामलों पर आगे चर्चा करने का कोई मतलब नहीं है। अगला, "सामान्य" कोड में केवल वास्तविक त्रुटियों पर विचार किया जाएगा।

Azure.Core

V3001 बायीं ओर और '<' ऑपरेटर के दाईं ओर समान उप-अभिव्यक्ति 'बफर.लिफ्ट' हैं। AzureBaseBuffersExtensions.cs 30

 public static async Task WriteAsync(...., ReadOnlyMemory<byte> buffer, ....) { byte[]? array = null; .... if (array == null || buffer.Length < buffer.Length) // <= { if (array != null) ArrayPool<byte>.Shared.Return(array); array = ArrayPool<byte>.Shared.Rent(buffer.Length); } if (!buffer.TryCopyTo(array)) throw new Exception("could not rent large enough buffer."); .... } 

हालत में त्रुटि शायद कॉपी-पेस्ट का परिणाम थी। इस तथ्य के अनुसार कि बफर को सरणी में कॉपी किया गया है, चेक को ऐसा दिखना चाहिए:

 if (array == null || array.Length < buffer.Length) 

वैसे भी, जैसा कि मैं हमेशा कहता हूं, कोड लेखक को ऐसी त्रुटियों को ठीक करने से निपटना चाहिए।

V3083 ईवेंट '_onChange', NullReferenceException का असुरक्षित आह्वान संभव है। इसे लागू करने से पहले एक स्थानीय चर को घटना असाइन करने पर विचार करें। ClientOptionsMonitor.cs 44

 private event Action<TOptions, string> _onChange; .... private void InvokeChanged(....) { .... if (_onChange != null) { _onChange.Invoke(options, name); } } 

महत्वपूर्ण नहीं है, लेकिन एक त्रुटि यहाँ है। अशक्त और उसके मंगलाचरण के लिए घटना की जाँच करने के बीच उपभोक्ता घटना से हटा सकता है। तब _onChange चर शून्य हो जाएगा और एक अपवाद फेंक दिया जाएगा। इस कोड को सुरक्षित तरीके से फिर से लिखना होगा। उदाहरण के लिए, निम्नानुसार है:

 private void InvokeChanged(....) { .... _onChange?.Invoke(options, name); } 

Azure.Messaging.EventHubs

V3080 संभव अशक्तता । 'EventPropertyValue' का निरीक्षण करने पर विचार करें। AmqpMessageConverter.cs 650

 private static bool TryCreateEventPropertyForAmqpProperty( object amqpPropertyValue, out object eventPropertyValue) { eventPropertyValue = null; .... switch (GetTypeIdentifier(amqpPropertyValue)) { case AmqpProperty.Type.Byte: .... case AmqpProperty.Type.String: eventPropertyValue = amqpPropertyValue; return true; .... } .... switch (amqpPropertyValue) { case AmqpSymbol symbol: eventPropertyValue = ....; break; case byte[] array: eventPropertyValue = ....; break; case ArraySegment<byte> segment when segment.Count == segment.Array.Length: eventPropertyValue = ....; break; case ArraySegment<byte> segment: .... eventPropertyValue = ....; break; case DescribedType described when (described.Descriptor is AmqpSymbol): eventPropertyValue = ....; break; default: var exception = new SerializationException( string.Format(...., eventPropertyValue.GetType().FullName)); // <= .... } return (eventPropertyValue != null); } 

आइए देखते हैं कि दिए गए कोड टुकड़े में EventPropertyValue चर मान के साथ क्या होता है। चर को विधि की शुरुआत में रिक्त सौंपा गया है। इसके अलावा, पहले स्विच स्थितियों में से एक में, चर आरंभीकृत किया जाता है, जिसके बाद विधि बाहर निकलती है। दूसरे स्विच ब्लॉक में कई स्थितियां होती हैं, जिनमें से प्रत्येक में चर को एक नया मान भी मिलता है। जबकि डिफ़ॉल्ट ब्लॉक में, EventPropertyValue चर का उपयोग बिना किसी जांच के किया जाता है, जो कि एक गलती है, क्योंकि इस समय चर शून्य है ।

V3066 'EventHubConsumer' कंस्ट्रक्टर: 'partitionId' और 'ConsumerGroup' को दिए गए तर्कों का संभावित गलत क्रम। TrackOneEventHubClient.cs 394

 public override EventHubConsumer CreateConsumer(....) { return new EventHubConsumer ( new TrackOneEventHubConsumer(....), TrackOneClient.EventHubName, partitionId, // <= 3 consumerGroup, // <= 4 eventPosition, consumerOptions, initialRetryPolicy ); } 

EventHubConsumer क्लास कंस्ट्रक्टर को कॉल करते समय विश्लेषक ने तीसरे और चौथे तर्क के भ्रमित क्रम पर संदेह किया। तो चलिए इस कंस्ट्रक्टर घोषणा को देखें:

 internal EventHubConsumer(TransportEventHubConsumer transportConsumer, string eventHubName, string consumerGroup, // <= 3 string partitionId, // <= 4 EventPosition eventPosition, EventHubConsumerOptions consumerOptions, EventHubRetryPolicy retryPolicy) { .... } 

दरअसल, तर्क मिश्रित होते हैं। मैं सुझाव दूंगा कि त्रुटि कैसे हुई। शायद, गलत कोड फॉर्मेटिंग को दोष देना है। बस EventHubConsumer कंस्ट्रक्टर घोषणा पर एक और नज़र डालें। इस तथ्य के कारण कि पहला TransportConsumer पैरामीटर वर्ग नाम के साथ एक ही लाइन पर है, ऐसा लग सकता है कि पार्टीशन पैरामीटर तीसरे स्थान पर है, न कि चौथे (पैरामीटर संख्याओं के साथ मेरी टिप्पणी मूल कोड में उपलब्ध नहीं है) । यह सिर्फ एक अनुमान है, लेकिन मैं कंस्ट्रक्टर कोड को निम्न में परिवर्तित करूंगा:

 internal EventHubConsumer ( TransportEventHubConsumer transportConsumer, string eventHubName, string consumerGroup, string partitionId, EventPosition eventPosition, EventHubConsumerOptions consumerOptions, EventHubRetryPolicy retryPolicy) { .... } 

Azure.Storage

V3112 इसी तरह की तुलना के भीतर एक असामान्यता। यह संभव है कि एक टाइपो अभिव्यक्ति के अंदर मौजूद है 'ContentLanguage == other.ContentEncoding'। BlobSasBuilder.cs 410

 public struct BlobSasBuilder : IEquatable<BlobSasBuilder> { .... public bool Equals(BlobSasBuilder other) => BlobName == other.BlobName && CacheControl == other.CacheControl && BlobContainerName == other.BlobContainerName && ContentDisposition == other.ContentDisposition && ContentEncoding == other.ContentEncoding && // <= ContentLanguage == other.ContentEncoding && // <= ContentType == other.ContentType && ExpiryTime == other.ExpiryTime && Identifier == other.Identifier && IPRange == other.IPRange && Permissions == other.Permissions && Protocol == other.Protocol && StartTime == other.StartTime && Version == other.Version; } 

असावधानी से हुई गलती। कोड समीक्षा के साथ ऐसी त्रुटि ढूंढना काफी कठिन है। यहाँ कोड का सही संस्करण है:

  .... ContentEncoding == other.ContentEncoding && ContentLanguage == other.ContentLanguage && .... 

V3112 इसी तरह की तुलना के भीतर एक असामान्यता। यह संभव है कि एक टाइपो अभिव्यक्ति के अंदर मौजूद है 'ContentLanguage == other.ContentEncoding'। FileSasBuilder.cs 265

 public struct FileSasBuilder : IEquatable<FileSasBuilder> { .... public bool Equals(FileSasBuilder other) => CacheControl == other.CacheControl && ContentDisposition == other.ContentDisposition && ContentEncoding == other.ContentEncoding // <= && ContentLanguage == other.ContentEncoding // <= && ContentType == other.ContentType && ExpiryTime == other.ExpiryTime && FilePath == other.FilePath && Identifier == other.Identifier && IPRange == other.IPRange && Permissions == other.Permissions && Protocol == other.Protocol && ShareName == other.ShareName && StartTime == other.StartTime && Version == other.Version ; 

बहुत समान कोड में एक ही त्रुटि है। कोड की प्रतिलिपि बनाई जा सकती है और आंशिक रूप से बदल दी गई है। लेकिन त्रुटि बनी रही।

Microsoft.Azure.Batch

V3053 एक अत्यधिक अभिव्यक्ति। 'आईलिस्ट' और 'लिस्ट' के सब्स्टीट्यूशन का परीक्षण करें। प्रॉपर्टीडाटा। 157

V3053 एक अत्यधिक अभिव्यक्ति। 'लिस्ट' और 'IReadOnlyList' की जाँच करें। प्रॉपर्टीडाटा। 158

 public class PropertyData { .... public bool IsTypeCollection => this.Type.Contains("IList") || this.Type.Contains("IEnumerable") || this.Type.Contains("List") || // <= this.Type.Contains("IReadOnlyList"); // <= } 

विश्लेषक ने व्यर्थ या गलत जाँच के बारे में दो चेतावनी जारी की। पहले मामले में, "IList" की खोज के बाद "सूची" के विकल्प की खोज बेमानी लगती है। यह सच है, यह शर्त:

 this.Type.Contains("IList") || this.Type.Contains("List") 

निम्नलिखित के लिए अच्छी तरह से बदला जा सकता है:

 this.Type.Contains("List") 

दूसरे मामले में, "IReadOnlyList" विकल्प के लिए खोज व्यर्थ है, जैसा कि पहले एक छोटे विकल्प "सूची" के लिए खोजा गया है।

एक मौका यह भी है कि खोज सब्सट्रिंग्स में स्वयं त्रुटियां हैं और कुछ और होना चाहिए। वैसे भी, केवल कोड लेखक को दोनों टिप्पणियों को ध्यान में रखते हुए सही कोड संस्करण का सुझाव देना है।

V3095 'httpRequest.Content.Headers' ऑब्जेक्ट का उपयोग इससे पहले कि यह शून्य के खिलाफ सत्यापित किया गया था। जाँच लाइनें: 76, 79. बैचबैडकेअर क्रेडेंशियल .cs 76

 public override Task ProcessHttpRequestAsync( HttpRequestMessage httpRequest, ....) { .... signature.Append(httpRequest.Content != null && httpRequest.Content.Headers.Contains("Content-Language") ? .... : ....; long? contentLength = httpRequest.Content?.Headers?.ContentLength; .... } 

HttpRequest.Content.Headers वैरिएबल का उपयोग पहले बिना किसी जाँच के किया जाता है, लेकिन बाद में इसे सशर्त एक्सेस ऑपरेटर का उपयोग करके संबोधित किया जाता है।

V3125 नल के खिलाफ सत्यापित होने के बाद 'omPropertyData' ऑब्जेक्ट का उपयोग किया गया था। चेक लाइन्स: 156, 148। कोड-जेनरेशन यूटिलिटीज ।cs 156

 private static string GetProtocolCollectionToObjectModelCollectionString( ...., PropertyData omPropertyData, ....) { if (IsMappedEnumPair(omPropertyData?.GenericTypeParameter, ....)) { .... } if (IsTypeComplex(omPropertyData.GenericTypeParameter)) .... } 

और यहाँ एक रिवर्स स्थिति है। एक कोड ब्लॉक में omPropertyData संभावित रूप से रिक्त संदर्भ के लिए सुरक्षित पहुंच संस्करण शामिल है। कोड में आगे, यह संदर्भ बिना किसी चेक के संभाला जाता है।

V3146 'मूल्य' के संभावित अशक्तता । 'FirstOrDefault' डिफ़ॉल्ट अशक्त मान लौटा सकता है। बैचशेयरकेक्रेडिऐडिएंट.केएस 127

 public override Task ProcessHttpRequestAsync(HttpRequestMessage httpRequest, ....) { .... foreach (string canonicalHeader in customHeaders) { string value = httpRequest.Headers. GetValues(canonicalHeader).FirstOrDefault(); value = value.Replace('\n', ' ').Replace('\r', ' ').TrimStart(); .... } .... } 

FirstOrDefault विधि के कारण, यदि खोज विफल हो जाती है, तो डिफ़ॉल्ट मान वापस आ जाएगा, जो स्ट्रिंग प्रकार के लिए अशक्त है । मान को मान चर के लिए सौंपा जाएगा, जो बाद में बिना किसी चेक के रिप्लेसमेंट विधि के साथ कोड में उपयोग किया जाता है। कोड को सुरक्षित बनाया जाना चाहिए। उदाहरण के लिए, निम्नानुसार है:

 foreach (string canonicalHeader in customHeaders) { string value = httpRequest.Headers. GetValues(canonicalHeader).FirstOrDefault(); value = value?.Replace('\n', ' ').Replace('\r', ' ').TrimStart(); .... } 

Microsoft.Azure.ServiceBus

V3121 'फ्लैगस' विशेषता के साथ एक गणन 'ब्लॉकशूटिंग' घोषित किया गया था, लेकिन डिफ़ॉल्ट मानों को ओवरराइड करने के लिए कोई इनिशियलाइज़र सेट नहीं करता है। Fx.cs 69

 static class Fx { .... public static class Tag { .... [Flags] public enum BlocksUsing { MonitorEnter, MonitorWait, ManualResetEvent, AutoResetEvent, AsyncResult, IAsyncResult, PInvoke, InputQueue, ThreadNeutralSemaphore, PrivatePrimitive, OtherInternalPrimitive, OtherFrameworkPrimitive, OtherInterop, Other, NonBlocking, } .... } .... } 

गणन को झंडे की विशेषता के साथ घोषित किया जाता है। एक ही समय में, लगातार मान डिफ़ॉल्ट रूप से छोड़ दिए जाते हैं ( मॉनिटरएंटर = 0 , मॉनिटरवेट = 1 , मैनुअलएनेटईवेंट = 2 और इसी तरह)। यह निम्नलिखित मामले में परिणाम हो सकता है: जब झंडे संयोजन का उपयोग करने की कोशिश कर रहा है, उदाहरण के लिए, दूसरा और तीसरा स्थिरांक मॉनिटरवेट (=) | ManualResetEvent (= 2) , एक अद्वितीय मान प्राप्त नहीं होगा, लेकिन डिफ़ॉल्ट 3 के साथ स्थिरांक डिफ़ॉल्ट रूप से (AutoResetEvent )। यह कॉलर कोड के लिए एक आश्चर्य के रूप में आ सकता है। यदि ब्लॉकिंगसिंग एन्यूमरेशन का उपयोग वास्तव में झंडे संयोजन (बिट फ़ील्ड) स्थापित करने के लिए किया जाता है, तो स्थिरांक को मान दिया जाना चाहिए, संख्या के बराबर जो दो की शक्तियां हैं।

 [Flags] public enum BlocksUsing { MonitorEnter = 1, MonitorWait = 2, ManualResetEvent = 4, AutoResetEvent = 8, AsyncResult = 16, IAsyncResult = 32, PInvoke = 64, InputQueue = 128, ThreadNeutralSemaphore = 256, PrivatePrimitive = 512, OtherInternalPrimitive = 1024, OtherFrameworkPrimitive = 2048, OtherInterop = 4096, Other = 8192, NonBlocking = 16384, } 

V3125 'सत्र' ऑब्जेक्ट का उपयोग नल के खिलाफ सत्यापित होने के बाद किया गया था। चेक लाइनें: 69, 68. AmqpLinkCreator.cs 69

 public async Task<Tuple<AmqpObject, DateTime>> CreateAndOpenAmqpLinkAsync() { .... AmqpSession session = null; try { // Create Session .... } catch (Exception exception) { .... session?.Abort(); throw AmqpExceptionHelper.GetClientException(exception, null, session.GetInnerException(), amqpConnection.IsClosing()); } .... } 

कैच ब्लॉक में सेशन चर हैंडलिंग पर ध्यान दें। एबॉर्ट पद्धति को सशर्त एक्सेस ऑपरेटर द्वारा सुरक्षित रूप से कहा जाता है। लेकिन GetInnerException विधि के बाद इसे बेवजह कहा जाता है। ऐसा करने में, अपेक्षित प्रकार के अपवाद के बजाय NullReferenceException को फेंका जा सकता है। यह कोड तय करना होगा। AmqpExceptionHelper.GetClientException विधि इनरसेप्शन पैरामीटर के लिए शून्य मान को पारित करने का समर्थन करती है:

 public static Exception GetClientException( Exception exception, string referenceId = null, Exception innerException = null, bool connectionError = false) { .... } 

इसलिए, कोई सत्र बुलाने पर केवल सशर्त अभिगम ऑपरेटर का उपयोग कर सकता है। GetInnerException () :

 public async Task<Tuple<AmqpObject, DateTime>> CreateAndOpenAmqpLinkAsync() { .... AmqpSession session = null; try { // Create Session .... } catch (Exception exception) { .... session?.Abort(); throw AmqpExceptionHelper.GetClientException(exception, null, session?.GetInnerException(), amqpConnection.IsClosing()); } .... } 

निष्कर्ष

जैसा कि आप देख सकते हैं, एक बड़ी परियोजना का आकार हमेशा बहुत सारी त्रुटियों की गारंटी नहीं देता है। हालांकि, हम सतर्क रहते हैं क्योंकि हम हमेशा कुछ पा सकते हैं। यहां तक ​​कि .NET के लिए Azure SDK के रूप में संरचनात्मक रूप से जटिल परियोजना में। कुछ महत्वपूर्ण दोषों को खोजने के लिए अतिरिक्त प्रयासों की आवश्यकता होती है। लेकिन अधिक कठिनाइयों परिणाम सुखद अधिक है। दूसरी ओर, अनुचित प्रयासों से बचने के लिए, हम नए कोड लिखते समय डेवलपर्स के कंप्यूटर पर स्थिर विश्लेषण का उपयोग करने की सलाह देते हैं। यह सबसे प्रभावी दृष्टिकोण है। डाउनलोड करें और कार्रवाई में पीवीएस-स्टूडियो का प्रयास करें । लड़ाई के कीड़े में गुड लक!