एज़्योर पॉवरशेल: ज्यादातर हानिरहित

सभी को नमस्कार। आज हमारे पास चेक पर एक और माइक्रोसॉफ्ट प्रोजेक्ट है। इस लेख के शीर्षक से, आप अनुमान लगा सकते हैं कि इस बार डेवलपर्स ने हमें बड़ी संख्या में त्रुटियों के साथ "कृपया" नहीं किया। हमें उम्मीद है कि परियोजना के लेखक शीर्षक से नाराज नहीं होंगे। आखिर, त्रुटियों की एक छोटी संख्या महान है, है ना? हालाँकि, हम अभी भी Azure PowerShell कोड में कुछ पेचीदा खोजने में कामयाब रहे। हम सुझाव देते हैं कि इस परियोजना की विशेषताओं को जानना और त्रुटियों की जांच करना, PVS-Studio C # विश्लेषक का उपयोग करना पाया गया।

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

Azure PowerShell कमांडलेट्स ( cmdlet ) का एक सेट है जो आपको PowerShell कमांड लाइन से सही Azure संसाधनों का प्रबंधन करने देता है। इस सेट का मुख्य उद्देश्य अध्ययन की प्रक्रिया को सरल बनाना और जल्दी से एज़्योर के लिए विकास शुरू करना है। Azure PowerShell Microsoft Azure एप्लिकेशन बनाने, परिनियोजित करने और प्रबंधित करने के लिए आकर्षक सुविधाएँ प्रशासक और डेवलपर्स प्रदान करता है।

Azure PowerShell को .NET मानक वातावरण में विकसित किया गया है, जो Windows और PowerShell 6.x के लिए PowerShell 5.1 और बाद में सभी प्लेटफ़ॉर्म द्वारा समर्थित है। GureHub पर Azure PowerShell स्रोत कोड उपलब्ध है।

हाल ही में मुझे अक्सर चेक के लिए Microsoft प्रोजेक्ट मिल रहे हैं। मेरी राय में, इन परियोजनाओं की गुणवत्ता आमतौर पर शीर्ष पायदान पर है। हालांकि, निश्चित रूप से, अपवाद के बिना नहीं, जैसा कि लेख " WinForms: त्रुटियां, होम्स " में वर्णित है। लेकिन इस बार सब कुछ ठीक है। परियोजना बड़ी है: 6845 .cs स्रोत कोड फ़ाइलों में लगभग 700,000 पंक्तियाँ होती हैं, जिनमें रिक्त स्थान होते हैं (मैं तीसरे स्तर के परीक्षण और चेतावनियों को ध्यान में नहीं रखता)। कोड की ऐसी राशि के लिए बहुत कम त्रुटियां पाई गईं: सौ से अधिक नहीं। इसी तरह के कई मामले थे, इसलिए मैंने लेख के लिए सबसे दिलचस्प चुना। आमतौर पर, मैंने पीवीएस-स्टूडियो चेतावनियों की संख्याओं के आधार पर त्रुटियों को हल किया।

इसके अलावा मैं कुछ कोड टुकड़ों पर ठोकर खाई, जो त्रुटियों की तरह दिखते थे, लेकिन निश्चित रूप से त्रुटिपूर्ण के रूप में पहचाने नहीं जा सकते थे, क्योंकि मैं PowerShell विकास की विशिष्टताओं से परिचित नहीं हूं। मुझे उम्मीद है कि पाठकों के बीच इस मुद्दे के विशेषज्ञ होंगे जो मेरी मदद करेंगे। मैं इसे नीचे विस्तार से बताऊंगा।

प्रतिक्रिया भाग से पहले, मैं परियोजना की विशिष्ट संरचना का उल्लेख करना चाहूंगा। Azure PowerShell स्रोत कोड में सत्तर से अधिक Visual Studio समाधान होते हैं। कुछ समाधानों में अन्य से परियोजनाएं शामिल हैं। इस संरचना ने विश्लेषण को थोड़ा धीमा कर दिया (बहुत अधिक नहीं)। फिर भी चेक किसी अन्य कठिनाइयों का कारण नहीं बना। सुविधा के लिए, त्रुटि संदेश (कोष्ठक में) मैं उस समाधान का नाम निर्दिष्ट करूंगा जहां त्रुटि पाई गई थी।

विश्लेषण के परिणाम

V3001 समान उप-अभिव्यक्तियाँ हैं 'strTimespan.Contains ("M") बाईं ओर और' दाईं ओर '|| ऑपरेटर। AzureServiceBusCmdletBase.cs 187 (EventGrid)

public static TimeSpan ParseTimespan(string strTimespan) { .... if (strTimespan.Contains("P") || strTimespan.Contains("D") || strTimespan.Contains("T") || strTimespan.Contains("H") || strTimespan.Contains("M") || strTimespan.Contains("M")) .... } 

एक स्पष्ट त्रुटि का एक उदाहरण जो केवल एक डेवलपर ही ठीक कर सकता है। इस मामले में, यह बिल्कुल स्पष्ट नहीं है कि क्या हम कोड डुप्लीकेशन से निपटते हैं जो कुछ भी प्रभावित करता है या कुछ और नहीं है, दो अंतिम जांचों में से एक में "एम" के बजाय जगह लेना है।

V3001 समान उप-अभिव्यक्तियाँ हैं 'this.AggregationType! = Null' बाईं ओर और '&&' ऑपरेटर के दाईं ओर। GetAzureRmMetricCommand.cs 156 (मॉनिटर)

 public AggregationType? AggregationType { get; set; } .... protected override void ProcessRecordInternal() { .... string aggregation = (this.AggregationType != null && this.AggregationType.HasValue) ? this.AggregationType.Value.ToString() : null; .... } 

यहाँ शायद कोई त्रुटि नहीं है। यह निरर्थक कोड का एक उदाहरण है। कभी-कभी ऐसे कोड डेवलपर के ज्ञान की कमी का संकेत दे सकते हैं। मुद्दा यह है कि यह जाँच करता है। एग्रीगेटेशन टाइप! = अशक्त और यह। एग्रीग्रेशनटाइप.हासवायु समान हैं। यह उनमें से केवल एक (किसी एक) का उपयोग करने के लिए पर्याप्त है। व्यक्तिगत रूप से, मुझे HasValue के साथ विकल्प पसंद है :

 string aggregation = this.AggregationType.HasValue ? this.AggregationType.Value.ToString() : null; 

V3003 'if (A) {...} का उपयोग if (A) {...}' पैटर्न का पता चला। तार्किक त्रुटि उपस्थिति की संभावना है। चेक लाइनें: 152, 163. GetAzureRmRecoveryServicesBackupProtectionPolicy.cs 152 (RecoveryServices)

 public override void ExecuteCmdlet() { .... if( WorkloadType == Models.WorkloadType.AzureVM ) { .... } .... else if( WorkloadType == Models.WorkloadType.AzureFiles ) { if( BackupManagementType != Models.BackupManagementType.AzureStorage ) { throw new ArgumentException( Resources.AzureFileUnsupportedBackupManagementTypeException ); } serviceClientProviderType = ServiceClientHelpers. GetServiceClientProviderType( Models.WorkloadType.AzureFiles ); } else if( WorkloadType == Models.WorkloadType.AzureFiles ) { if( BackupManagementType != Models.BackupManagementType.AzureStorage ) { throw new ArgumentException( Resources.AzureFileUnsupportedBackupManagementTypeException ); } serviceClientProviderType = ServiceClientHelpers. GetServiceClientProviderType( Models.WorkloadType.AzureFiles ); } .... } 

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

V3005 'this.VM.OSProfile.WindowsConfiguration.ProvisionVMAgent' वेरिएबल खुद को सौंपा गया है। SetAzureVMOperatingSystemCommand.cs 298 (गणना)

 public override void ExecuteCmdlet() { .... // OS Profile this.VM.OSProfile.WindowsConfiguration.ProvisionVMAgent = this.VM.OSProfile.WindowsConfiguration.ProvisionVMAgent; .... } 

संपत्ति का मूल्य स्व-नियत है। इसकी घोषणा पर एक नज़र:

 [JsonProperty(PropertyName = "provisionVMAgent")] public bool? ProvisionVMAgent { get; set; } 

JsonProperty विवरण बताता है: "Newtonsoft.Json.JsonSerializer को हमेशा निर्दिष्ट नाम के साथ सदस्य को क्रमबद्ध करने का निर्देश देता है।" ऐसा लगता है कि सब कुछ दोषी है और स्पष्ट त्रुटि हुई है। संपत्ति तक पहुंचने के लिए इसका स्पष्ट उपयोग भी काफी भ्रामक है। शायद, इसके बजाय एक अन्य चर को गलती से निर्दिष्ट नहीं किया गया था । लेकिन चलो निष्कर्ष पर नहीं कूदते। इस तथ्य का तथ्य यह है कि मैं इस तरह के बहुत सारे कामों में आया था (एक संपत्ति स्व-नियत है)। यहाँ एक असाइनमेंट का एक उदाहरण है, एक त्रुटि के समान:

V3005 'this.LastHeartbeat' चर अपने आप को सौंपा गया है। PSFabricDetails.cs 804 (RecoveryServices)

 public ASRInMageAzureV2SpecificRPIDetails( InMageAzureV2ReplicationDetails details) { this.LastHeartbeat = this.LastHeartbeat; // <= this.RecoveryAvailabilitySetId = details.RecoveryAvailabilitySetId; this.AgentVersion = details.AgentVersion; this.DiscoveryType = details.DiscoveryType; .... } 

दूसरे और बाद के असाइनमेंट पर करीब से नजर डालते हैं। अभिव्यक्ति के दाहिने हिस्से में, इसके बजाय विवरण होता है । अब इस घोषणा को देखें। LastHeartbeat संपत्ति:

 public DateTime? LastHeartbeat { get; set; } 

अंत में, आइए InMageAzureV2ReplicationDetails वर्ग में समान नाम वाली प्रॉपर्टी ढूंढें । ऐसी संपत्ति वहाँ घोषित की जाती है:

 public class InMageAzureV2ReplicationDetails : ReplicationProviderSpecificSettings { .... [JsonProperty(PropertyName = "lastHeartbeat")] public DateTime? LastHeartbeat { get; set; } .... } 

खैर, इस मामले में, मैं यह स्वीकार करना चाहता हूं कि यह एक वास्तविक त्रुटि है। लेकिन हम अगले चेतावनियों के साथ क्या करेंगे? दो पिछले कोड अंशों के विपरीत, कई स्व-निर्दिष्ट गुण हैं। खैर, यह एक त्रुटि की तरह कम दिखता है:

• V3005 'this.ResourceGroupName' वेरिएबल को ही असाइन किया गया है। RemoveAzureRmExpressRouteConnectionCommand.cs 84 (संज्ञानात्मक सेवाएँ)
• V3005 'this.ExpressRouteGatewayName' वेरिएबल खुद को सौंपा गया है। RemoveAzureRmExpressRouteConnectionCommand.cs 85 (CognitiveServices)
• V3005 'this.Name' वैरिएबल को ही असाइन किया गया है। RemoveAzureRmExpressRouteConnectionCommand.cs 86 (संज्ञानात्मक सेवाएँ)

 [Cmdlet(VerbsCommon.Remove, ResourceManager.Common.AzureRMConstants.AzureRMPrefix + "ExpressRouteConnection", DefaultParameterSetName = CortexParameterSetNames.ByExpressRouteConnectionName, SupportsShouldProcess = true), OutputType(typeof(bool))] public class RemoveExpressRouteConnectionCommand : ExpressRouteConnectionBaseCmdlet { [Parameter( Mandatory = true, ParameterSetName = CortexParameterSetNames.ByExpressRouteConnectionName, HelpMessage = "The resource group name.")] [ResourceGroupCompleter] [ValidateNotNullOrEmpty] public string ResourceGroupName { get; set; } .... public override void Execute() { if (....) { this.ResourceGroupName = this.ResourceGroupName; this.ExpressRouteGatewayName = this.ExpressRouteGatewayName; this.Name = this.Name; } .... } .... } 

Execute पद्धति में एक पंक्ति में तीन गुण-कार्य होते हैं। बस के मामले में, मैंने क्लास RemoveExpressRouteConnectionCommand और इसकी सभी विशेषताओं के साथ-साथ रिसोर्सग्रुपनाम की संपत्ति घोषणा (अन्य दो संपत्तियों को समान तरीके से घोषित किया गया है) की पूर्ण घोषणा का हवाला दिया। यह इन चेतावनियों ने मुझे इस सवाल के बारे में सोचने पर मजबूर कर दिया: "क्या यह एक त्रुटि है?" मुझे संदेह है कि PowerShell विकास के कुछ आंतरिक जादू यहां हो रहे हैं। मुझे उम्मीद है कि पाठकों के बीच ऐसे विशेषज्ञ होंगे जिन्हें इस मुद्दे के बारे में सूचित किया जाता है। मैं इस मामले में कोई निष्कर्ष निकालने के लिए तैयार नहीं हूं।

V3006 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। 'थ्रो' कीवर्ड गायब हो सकता है: नए ArgumentException (FOO) को फेंकें। StartAzureRmRecoveryServicesAsrestestailoverJob.cs 259 (RecoveryServices)

 private void StartRPITestFailover() { .... if (....) { .... } else { new ArgumentException( Resources .UnsupportedDirectionForTFO); // Throw Unsupported Direction // Exception } .... } 

थ्रो कीवर्ड छोड़ा गया है। और टिप्पणी कहती है कि अपवाद को सिर्फ फेंकना है। मुझे RecoveryServices समाधान में कई और समान त्रुटियों का सामना करना पड़ा:

• V3006 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। 'थ्रो' कीवर्ड गायब हो सकता है: नए ArgumentException (FOO) को फेंकें। StartAzureRmRecoveryServicesArTestFailoverJob.cs 305 (RecoveryServices)
• V3006 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। 'थ्रो' कीवर्ड गायब हो सकता है: नए ArgumentException (FOO) को फेंकें। StartAzureRmRecoveryServicesArPlannedFailover.cs 278 (RecoveryServices)
• V3006 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। 'थ्रो' कीवर्ड गायब हो सकता है: नए ArgumentException (FOO) को फेंकें। StartAzureRmRecoveryServicesAsrUnPlannedFailover.cs 322 (RecoveryServices)
• V3006 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। 'थ्रो' कीवर्ड गायब हो सकता है: नए ArgumentException (FOO) को फेंकें। UpdateAzureRmRecoveryServicesArProtectionDirection.cs 421 (RecoveryServices)
• V3006 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। 'थ्रो' कीवर्ड गायब हो सकता है: नए ArgumentException (FOO) को फेंकें। UpdateAzureRmRecoveryServicesArProtectionDirection.cs 452 (RecoveryServices)

V3022 अभिव्यक्ति 'apiType.HasValue' हमेशा गलत है। ApiManagementClient.cs 1134 (ApiManagement)

 private string GetApiTypeForImport(...., PsApiManagementApiType? apiType) { .... if (apiType.HasValue) { switch(apiType.Value) { case PsApiManagementApiType.Http: return SoapApiType.SoapToRest; case PsApiManagementApiType.Soap: return SoapApiType.SoapPassThrough; default: return SoapApiType.SoapPassThrough; } } return apiType.HasValue ? // <= apiType.Value.ToString("g") : PsApiManagementApiType.Http.ToString("g"); } 

काम का तर्क टूट गया है। यदि ApiType में कोई मान है, तो नियंत्रण पद्धति के अंत में रिटर्न एक्सप्रेशन तक नहीं पहुंचेगा (सभी स्विच शाखाओं में रिटर्न होता है )। अन्यथा, विधि हमेशा PsApiManagementApiType.ttp.ToString ("g") लौटाएगी , जबकि apiType.Value.ToString ("g") मान कभी वापस नहीं आएगा।

V3022 अभिव्यक्ति ' स्वचालनजोब ! = अशक्त && स्वचालनजोब == अशक्त' हमेशा गलत है। NodeConfigurationDeployment.cs 199 (स्वचालन)

 public NodeConfigurationDeployment( ...., Management.Automation.Models.Job automationJob = null, ....) { .... if (automationJob != null && automationJob == null) return; .... } 

काउंटर-सहज ज्ञान युक्त कोड। दो चेक जो एक दूसरे के विपरीत हैं। संभवत: अशक्त के लिए दूसरे चेक में गलत चर है।

V3022 अभिव्यक्ति हमेशा झूठी है। DataFactoryClient.Encrypt.cs 37 (DataFactory)

 public virtual string OnPremisesEncryptString(....) { .... if ( linkedServiceType == LinkedServiceType.OnPremisesSqlLinkedService && linkedServiceType == LinkedServiceType.OnPremisesOracleLinkedService && linkedServiceType == LinkedServiceType.OnPremisesFileSystemLinkedService && (value == null || value.Length == 0)) { throw new ArgumentNullException("value"); } .... } 

जाँच व्यर्थ है और अपवाद कभी नहीं फेंका जाएगा। शर्त के लिए तीन अलग-अलग मानों के साथ-साथ लिंक्डइन लिंक टाइप वेरिएबल की आवश्यकता होती है। संचालक && और || भ्रमित होने की संभावना है। निश्चित कोड:

 if (( linkedServiceType == LinkedServiceType.OnPremisesSqlLinkedService || linkedServiceType == LinkedServiceType.OnPremisesOracleLinkedService || linkedServiceType == LinkedServiceType.OnPremisesFileSystemLinkedService) && (value == null || value.Length == 0)) .... 

V3022 अभिव्यक्ति 'एकस == नल' हमेशा झूठी होती है। PSKeyVaultCertificatePolicy.cs 129 (KeyVault)

 internal CertificatePolicy ToCertificatePolicy() { .... if (Ekus != null) { x509CertificateProperties.Ekus = Ekus == null ? null : new List<string>(Ekus); } .... } 

अशक्त के लिए एकस चर का निरर्थक जाँच। यह शायद ठीक है, लेकिन कोड अच्छा नहीं लगता है।

V3023 इस अभिव्यक्ति का निरीक्षण करने पर विचार करें। अभिव्यक्ति अत्यधिक है या एक गलत चित्रण है। PolicyRetentionObjects.cs 207 (RecoveryServices)

 public virtual void Validate() { if (RetentionTimes == null || RetentionTimes.Count == 0 || RetentionTimes.Count != 1) { throw new ArgumentException( Resources.InvalidRetentionTimesInPolicyException); } } 

यहाँ अत्यधिक जाँच या अत्यधिक स्थिति है। Check RetentionTimes.Count == 0 व्यर्थ है, उसके बाद, RetentionTimes.Count चेक करें ! = = इस प्रकार है।

V3025 गलत प्रारूप। 'फ़ॉर्मेट' फ़ंक्शन को कॉल करते समय एक अलग प्रारूप प्रारूप की उम्मीद की जाती है। तर्क का उपयोग नहीं किया गया: यह। NewScheduledQueryRuleCommand.cs 117 (मॉनिटर)

 protected override void ProcessRecordInternal() { .... if (this.ShouldProcess(this.Name, string.Format("Creating Log Alert Rule '{0}' in resource group {0}", this.Name, this.ResourceGroupName))) { .... } .... } 

स्वरूपण पंक्ति में कोई त्रुटि। निर्दिष्ट {0} का उपयोग दो बार किया जाता है, और प्रारूप विधि को दो तर्क दिए जाते हैं। यहाँ सही संस्करण है:

 if (this.ShouldProcess(this.Name, string.Format("Creating Log Alert Rule '{0}' in resource group {1}", this.Name, this.ResourceGroupName))) .... 

इसी तरह की एक और त्रुटि:

• V3025 गलत प्रारूप। 'फ़ॉर्मेट' फ़ंक्शन को कॉल करते समय एक भिन्न स्वरूप की आइटम अपेक्षित है। तर्क का उपयोग नहीं किया गया: यह। RemoveScheduledQueryRuleCommand.cs 88 (मॉनिटर)

V3042 संभावित NullReferenceException। '?' और '' ऑपरेटरों का उपयोग 'imageAndOsType' ऑब्जेक्ट VirtualMachineScaleSetStrategy.cs 81 (गणना) के सदस्यों तक पहुँचने के लिए किया जाता है

 internal static ResourceConfig<VirtualMachineScaleSet> CreateVirtualMachineScaleSetConfig(...., ImageAndOsType imageAndOsType, ....) { .... VirtualMachineProfile = new VirtualMachineScaleSetVMProfile { OsProfile = new VirtualMachineScaleSetOSProfile { ...., WindowsConfiguration = imageAndOsType.CreateWindowsConfiguration(), // <= ...., }, StorageProfile = new VirtualMachineScaleSetStorageProfile { ImageReference = imageAndOsType?.Image, // <= DataDisks = DataDiskStrategy.CreateVmssDataDisks( imageAndOsType?.DataDiskLuns, dataDisks) // <= }, }, .... } 

VirtualMachineScaleSetVMProfile ऑब्जेक्ट बनाते समय, ImageAndOsType वैरिएबल को बिना किसी प्रारंभिक जाँच के नल के लिए चेक किया जाता है। हालाँकि, जब VirtualMachineScaleSetStorageProfile बनाते हैं, तो यह चर पहले ही सशर्त एक्सेस ऑपरेटर का उपयोग करके दो बार जांचा जाता है। कोड सुरक्षित नहीं दिखता है।

V3042 संभावित NullReferenceException। '?' और '' ऑपरेटरों को 'मौजूदा कॉन्टैक्ट्स' ऑब्जेक्ट के सदस्यों को एक्सेस करने के लिए उपयोग किया जाता है RemoveAzureKeyVaultCertificateContact.cs 123 (KeyVault)

 public override void ExecuteCmdlet() { .... List<PSKeyVaultCertificateContact> existingContacts; try { existingContacts = this.DataServiceClient. GetCertificateContacts(VaultName)?.ToList(); } catch (KeyVaultErrorException exception) { .... existingContacts = null; } foreach (var email in EmailAddress) { existingContacts.RemoveAll(....); // <= } .... } 

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

V3066 'PersistSyncServerRegistration' विधि: 'StorageSyncServiceUid' और 'searchUri' में पास किए गए तर्कों का संभावित गलत क्रम। EcsManagementInteropClient.cs 364 (StorageSync)

 public class EcsManagementInteropClient : IEcsManagement { .... public int PersistSyncServerRegistration(....) { return m_managementObject.PersistSyncServerRegistration( serviceUri, subscriptionId, storageSyncServiceName, resourceGroupName, clusterId, clusterName, storageSyncServiceUid, // <= discoveryUri, // <= serviceLocation, resourceLocation); } .... } 

विश्लेषक को संदेह था कि PersistSyncServerRegistration विधि के तर्कों का क्रम उलझा हुआ है। विधि की घोषणा:

 public interface IEcsManagement : IDisposable { .... int PersistSyncServerRegistration( [In, MarshalAs(UnmanagedType.BStr)] string serviceUri, [In, MarshalAs(UnmanagedType.BStr)] string subscriptionId, [In, MarshalAs(UnmanagedType.BStr)] string storageSyncServiceName, [In, MarshalAs(UnmanagedType.BStr)] string resourceGroupName, [In, MarshalAs(UnmanagedType.BStr)] string clusterId, [In, MarshalAs(UnmanagedType.BStr)] string clusterName, [In, MarshalAs(UnmanagedType.BStr)] string discoveryUri, // <= [In, MarshalAs(UnmanagedType.BStr)] string storageSyncServiceUid, // <= [In, MarshalAs(UnmanagedType.BStr)] string serviceLocation, [In, MarshalAs(UnmanagedType.BStr)] string resourceLocation); .... } 

दरअसल, यहाँ तर्क संख्या सात और आठ के साथ कुछ गलत है। लेखक को कोड की जांच करनी होगी।

V3077 'GetGuid' संपत्ति का सेटर इसके 'मान' पैरामीटर का उपयोग नहीं करता है। RecoveryServicesBackupCmdletBase.cs 54 (RecoveryServices)

 public abstract class RecoveryServicesBackupCmdletBase : AzureRMCmdlet { .... static string _guid; protected static string GetGuid { get { return _guid; } set { _guid = Guid.NewGuid().ToString(); } } .... } 

सेटर उत्तीर्ण पैरामीटर का उपयोग नहीं करता है। इसके बजाय, यह एक नया GUID बनाता है और इसे _guid फ़ील्ड में असाइन करता है। मुझे लगता है कि अधिकांश पाठक इस बात से सहमत होंगे कि ऐसा कोड कम से कम बदसूरत लगता है। यह निर्माण उपयोग करने के लिए बहुत सुविधाजनक नहीं है: जब (पुनः) GetGuid संपत्ति को इनिशियलाइज़ करना है, तो किसी को इसे एक नकली मूल्य प्रदान करना होगा, जो बहुत स्पष्ट नहीं है। लेकिन सबसे ज्यादा मुझे जिस तरह से लेखकों ने इस पैटर्न का इस्तेमाल किया उससे मैं चकित था। केवल एक ही जगह है, जहाँ गेटग्यूइड को संभाला जाता है। इसे देखें:

 public override void ExecuteCmdlet() { .... var itemResponse = ServiceClientAdapter.CreateOrUpdateProtectionIntent( GetGuid ?? Guid.NewGuid().ToString(), ....); .... } 

शानदार!

V3091 अनुभवजन्य विश्लेषण। यह संभव है कि एक टाइपो स्ट्रिंग शाब्दिक के अंदर मौजूद है: "प्रबंधन समूह आईडी।" 'ईद' शब्द संदिग्ध है। Constants.cs 36 (संसाधन)

 public class HelpMessages { public const string SubscriptionId = "Subscription Id of the subscription associated with the management"; public const string GroupId = "Management Group Id"; // <= public const string Recurse = "Recursively list the children of the management group"; public const string ParentId = "Parent Id of the management group"; public const string GroupName = "Management Group Id"; // <= public const string DisplayName = "Display Name of the management group"; public const string Expand = "Expand the output to list the children of the management group"; public const string Force = "Force the action and skip confirmations"; public const string InputObject = "Input Object from the Get call"; public const string ParentObject = "Parent Object"; } 

विश्लेषक ने GroupName स्थिरांक के लिए निर्दिष्ट स्ट्रिंग में संभावित त्रुटि की ओर इशारा किया। निष्कर्ष अन्य असाइनमेंट के अनुभवजन्य विश्लेषण पर आधारित है, चर के नामों को ध्यान में रखते हुए। मुझे लगता है कि इस मामले में विश्लेषक सही है, और GroupName कॉन्स्टेंटहोल्ड का मूल्य एक प्रकार का "प्रबंधन नाम" है। संभवतः इस तथ्य के कारण त्रुटि हुई कि GroupId स्थिरांक के लिए मूल्य की प्रतिलिपि बनाई गई थी, लेकिन परिवर्तित नहीं हुई।

इसी तरह की एक और त्रुटि:

• V3091 अनुभवजन्य विश्लेषण। यह संभव है कि एक टाइपो स्ट्रिंग शाब्दिक के अंदर मौजूद है। 'नाम' शब्द संदिग्ध है। ParamHelpMsgs.cs 153 (RecoveryServices)

V3093 '' | ' ऑपरेटर दोनों ऑपरेंड का मूल्यांकन करता है। शायद एक शॉर्ट-सर्किट '|| इसके बजाय ऑपरेटर का उपयोग किया जाना चाहिए। PSKeyVaultCertificatePolicy.cs 114 (KeyVault)

 internal CertificatePolicy ToCertificatePolicy() { .... if (!string.IsNullOrWhiteSpace(SubjectName) || DnsNames != null || Ekus != null || KeyUsage != null | // <= ValidityInMonths.HasValue) { .... } .... } 

इस खंड में एक त्रुटि हो सकती है और यदि दो अंतिम स्थितियों के बीच के ब्लॉक में है || ऑपरेटर का इस्तेमाल किया गया हो सकता है। लेकिन जैसा कि अक्सर होता है, केवल डेवलपर ही सही उत्तर दे सकता है।

V3095 नल के खिलाफ सत्यापित होने से पहले 'प्रमाण पत्र' ऑब्जेक्ट का उपयोग किया गया था। जाँच लाइनें: 41, 43. सर्टिफिकेटइन्फो। 41 (ऑटोमेशन)

 public CertificateInfo( ...., Azure.Management.Automation.Models.Certificate certificate) { .... this.Name = certificate.Name; if (certificate == null) return; .... } 

क्लासिक। पहले ऑब्जेक्ट का उपयोग किया जाता है और उसके बाद ही संदर्भ को शून्य के लिए जांचा जाता है। हम इस तरह की त्रुटियों के बहुत बार आते हैं। आइए एक और समान त्रुटि पर विचार करें।

V3095 नल के खिलाफ सत्यापित होने से पहले 'क्लस्टरक्रेड' ऑब्जेक्ट का उपयोग किया गया था। चेक लाइनें: 115, 118. इनवॉइकहोमकमांड.केएस 115 (एचडीआईनाइट)

 public override void ExecuteCmdlet() { .... _credential = new BasicAuthenticationCloudCredentials { Username = clusterCred.UserName, Password = clusterCred.Password.ConvertToString() }; if (clusterConnection == null || clusterCred == null) .... } 

यहाँ कुछ ऐसी ही त्रुटियाँ हैं:

• V3095 नल के खिलाफ सत्यापित होने से पहले '_profile' ऑब्जेक्ट का उपयोग किया गया था। जाँच लाइनें: 47, 49. RMProfileClient.cs 47 (लेखा)
• V3095 'this.oadBalancer.BackendAddressPools' ऑब्जेक्ट का उपयोग इससे पहले कि यह अशक्त के खिलाफ सत्यापित किया गया था। चेक लाइनें: 56, 63. AddAzureRmLoadBalancerBackendAddressPoolConfigCommand.cs 56 (संज्ञानात्मक सेवाएँ)
• सामान्यतया, मैंने Azure PowerShell कोड में कई V3095 त्रुटियां देखीं । लेकिन वे सभी काफी समान हैं, इसलिए मैं इस मुद्दे पर ध्यान नहीं दूंगा।

V3125 नल के खिलाफ सत्यापित होने के बाद ' startTime ' ऑब्जेक्ट का उपयोग किया गया था। चेक लाइन: 1752, 1738। स्वचालन।

 private string GetNodeReportListFilterString( ...., DateTimeOffset? startTime, ...., DateTimeOffset? lastModifiedTime) { .... if (startTime.HasValue) { odataFilter.Add("properties/startTime ge " + this.FormatDateTime(startTime.Value)); // <= } .... if (lastModifiedTime.HasValue) { odataFilter.Add("properties/lastModifiedTime ge " + this.FormatDateTime(startTime.Value)); // <= } .... } 

यह भी काफी व्यापक प्रकार की त्रुटियां हैं। पहली बार उपयोग किए जाने पर मूल्य उपस्थिति के लिए स्टार्टटाइम चर की जाँच की जाती है। लेकिन यह बाद के उपयोग में नहीं किया जाता है। खैर, स्थिति और भी खराब हो सकती है। दूसरे को देखो अगर ब्लॉक। मुझे लगता है कि startTime चर यहाँ बिल्कुल नहीं होना चाहिए। सबसे पहले, इसके उपयोग से पहले मूल्य की उपस्थिति के लिए कोई जांच नहीं है। दूसरे, ऐड मेथड को पास करने के लिए बनाई गई स्ट्रिंग भी मेरे सुझाव की पुष्टि करती है। इस स्ट्रिंग के पहले भाग में एक अन्य चर (lastModifiedTime ) का उल्लेख किया गया है।

V3125 नल के खिलाफ सत्यापित होने के बाद 'FirstPage' ऑब्जेक्ट का उपयोग किया गया था। चेक लाइन: 113, 108. इंटीग्रेशनएक्वांटगर्मेशनपरिवहन ।cs 113 (LogicApp)

 public IList<IntegrationAccountAgreement> ListIntegrationAccountAgreements(....) { var compositeList = new List<IntegrationAccountAgreement>(); var firstPage = this.LogicManagementClient. IntegrationAccountAgreements.List(....); if (firstPage != null) { compositeList.AddRange(firstPage); } if (!string.IsNullOrEmpty(firstPage.NextPageLink)) // <= { .... } .... } 

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

मैंने ऊपर वर्णित V3095 की तुलना में Azure PowerShell कोड में V3125 चेतावनियों के और भी अधिक पाया। ये सभी भी एक ही प्रकार के हैं। मुझे लगता है, उनमें से दो जिन्हें हमने माना है कि वे पर्याप्त हैं।

V3137 'apiVersionSetId' वैरिएबल असाइन किया गया है, लेकिन फ़ंक्शन के अंत तक उपयोग नहीं किया गया है। GetAzureApiManagementApiVersionSet.cs 69 (ApiManagement)

 public String ApiVersionSetId { get; set; } .... public override void ExecuteApiManagementCmdlet() { .... string apiVersionSetId; if (ParameterSetName.Equals(ContextParameterSet)) { .... apiVersionSetId = ApiVersionSetId; } else { apiVersionSetId = ....; } if (string.IsNullOrEmpty(ApiVersionSetId)) // <= { WriteObject(....); } else { WriteObject(Client.GetApiVersionSet(...., ApiVersionSetId)) // <= } } 

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

V3137 'cacheId' वेरिएबल असाइन किया गया है, लेकिन फ़ंक्शन के अंत तक उपयोग नहीं किया गया है। RemoveAzureApiManagementCache.cs 94 (ApiManagement)

 public String CacheId { get; set; } .... public override void ExecuteApiManagementCmdlet() { .... string cacheId; if (....) { .... cacheId = InputObject.CacheId; } else if (....) { .... cacheId = cache.CacheId; } else { .... cacheId = CacheId; } var actionDescription = string.Format(...., CacheId); // <= var actionWarning = string.Format(...., CacheId); // <= .... Client.CacheRemove(resourceGroupName, serviceName, CacheId); // <= .... } 

यह ऐसा मामला है जो पहले के वर्णित के लगभग समान है। किसी भी तरह से इनिशियलाइज़ेशन के बाद कैशीआईड लोकल वैरिएबल का उपयोग नहीं किया जाता है। इसके बजाय, CacheId के समान नाम वाली एक अन्य संपत्ति का उपयोग किया जाता है। मुझे यकीन नहीं है, यह हो सकता है कि Azure PowerShell डेवलपर्स का सिर्फ एक प्रोग्रामिंग पैटर्न हो। वैसे भी, यह एक त्रुटि की तरह दिखता है।

V3143 'मान' पैरामीटर को एक संपत्ति सेटर के अंदर फिर से लिखा जाता है, और उसके बाद इसका उपयोग नहीं किया जाता है। NewAzureIntegrationAccountPartnerCommand.cs 67 (LogicApp)

 [Parameter(Mandatory = false, HelpMessage = "The integration account partner type.", ValueFromPipelineByPropertyName = false)] [ValidateSet("B2B", IgnoreCase = false)] [ValidateNotNullOrEmpty] public string PartnerType { get { return this.partnerType; } set { value = this.partnerType; } // <= } 

साझेदार क्षेत्र को निम्नलिखित तरीके से घोषित किया गया है:

 /// <summary> /// Default partner type. /// </summary> private string partnerType = "B2B"; 

समाधान (LogicApp) के नाम के बावजूद जहां एक त्रुटि का पता चला था, मुझे इसमें तर्क नहीं मिला। सेटर में संशोधित मूल्य एक दुर्लभ घटना नहीं है, लेकिन इस मामले में यह मूल मूल्य के नुकसान से संबंधित है। यह अजीब लग रहा है। कोड में संपत्ति केवल एक बार पढ़ी जाती है। शायद, हमें फिर से विशेषज्ञों की सलाह लेने की ज़रूरत है। शायद मैं अभी नहीं मिलता। मुद्दा यह है कि मैं कई समान पैटर्न में आया था:

• V3143 'मान' पैरामीटर एक संपत्ति सेटर के अंदर फिर से लिखा जाता है, और उसके बाद इसका उपयोग नहीं किया जाता है। NewAzureIntegrationAccountSchemaCommand.cs 79 (LogicApp)
• V3143 'मान' पैरामीटर को एक संपत्ति सेटर के अंदर फिर से लिखा जाता है, और उसके बाद इसका उपयोग नहीं किया जाता है। NewAzureIntegrationAccountSchemaCommand.cs 87 (LogicApp)
• V3143 'मान' पैरामीटर एक संपत्ति सेटर के अंदर फिर से लिखा जाता है, और उसके बाद इसका उपयोग नहीं किया जाता है। UpdateAzureIntegrationAccountPartnerCommand.cs 67 (LogicApp)
• V3143 'मान' पैरामीटर एक संपत्ति सेटर के अंदर फिर से लिखा जाता है, और उसके बाद इसका उपयोग नहीं किया जाता है। UpdateAzureIntegrationAccountSchemaCommand.cs 80 (LogicApp)
• V3143 'मान' पैरामीटर को एक संपत्ति सेटर के अंदर फिर से लिखा जाता है, और उसके बाद इसका उपयोग नहीं किया जाता है। UpdateAzureIntegrationAccountSchemaCommand.cs 88 (LogicApp)

निष्कर्ष

ये सभी दिलचस्प बग्स हैं जो Azure PowerShell कोड में पाए गए थे। उत्साही और जो लोग रुचि रखते हैं वे इस (या किसी अन्य) परियोजना में त्रुटियों की समीक्षा करने के लिए स्वागत करते हैं। मैं शायद कुछ हटकर कर सकता हूं। समीक्षा करने के लिए, आपको केवल पीवीएस-स्टूडियो डाउनलोड और इंस्टॉल करना होगा।

अंत तक पढ़ने के लिए धन्यवाद। और, ज़ाहिर है, हर किसी के लिए बगलेस कोड!