Azure PowerShell: "ज्यादातर हानिरहित"

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

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

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 हजार लाइनें हैं, खाली को छोड़कर (परीक्षण, साथ ही तीसरे स्तर की विश्वसनीयता की चेतावनी, मैंने ध्यान नहीं दिया)। कोड की ऐसी मात्रा के लिए बहुत कम त्रुटियां थीं: सौ से अधिक नहीं। एक ही प्रकार की काफी कुछ स्थितियां हैं, इसलिए लेख के लिए मैंने सबसे दिलचस्प सकारात्मकता का चयन किया। त्रुटियों, जैसा कि मैं आमतौर पर करता हूं, पीवीएस-स्टूडियो डायग्नोस्टिक संख्याओं द्वारा हल किया जाता है।

मुझे कोड के टुकड़े भी आए, जो त्रुटियों की तरह दिखते हैं, लेकिन मैं वास्तविक समस्या के अस्तित्व के बारे में असंदिग्ध निष्कर्ष नहीं निकाल सका, क्योंकि मैं 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 वर्ग की पूरी घोषणा की, साथ ही साथ रिसोर्सग्रुपनाम की संपत्ति (अन्य दो संपत्तियों को उसी तरह से घोषित किया गया है) की घोषणा की। यह ऐसा ट्रिगर था जिसने मुझे इस सवाल के बारे में सोचने पर मजबूर कर दिया: "क्या यह एक गलती है?" मुझे संदेह है कि पावरशेल विकास के कुछ प्रकार के आंतरिक जादू यहां हो सकते हैं। मुझे उम्मीद है कि पाठकों के बीच ऐसे विशेषज्ञ हैं जो इस मामले में जानकार हैं। मैं इस मामले में कोई निष्कर्ष निकालने के लिए तैयार नहीं हूं।

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"); } 

काम के तर्क का उल्लंघन किया जाता है। यदि एपी टाइप में एक मान होता है, तो नियंत्रण विधि के अंत में रिटर्न एक्सप्रेशन तक नहीं पहुंचेगा (सभी स्विच शाखाओं में रिटर्न होता है )। अन्यथा, विधि हमेशा PsApiManagementApiType.Http.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"); } .... } 

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

 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); } } 

अत्यधिक जांच, या गलत स्थिति। RetentionTimes.Count == 0 की जाँच करने का कोई मतलब नहीं है, क्योंकि इसके बाद RetentionTimes.C = 1 की जाँच करें।

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 संपत्ति को प्रारंभ करना (फिर से), आपको इसे कुछ नकली मूल्य निर्दिष्ट करना होगा, जो पूरी तरह से अप्राप्य है। लेकिन इन सबसे मैं इस बात से चकित था कि लेखक स्वयं इस निर्माण का उपयोग कैसे करते हैं। कोड में केवल एक ही स्थान है जहां 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 (संज्ञानात्मक सेवाएँ)
• सामान्य तौर पर, एज़्योर पावरशेल कोड में, मुझे बहुत अधिक वी 3095 त्रुटियां हुईं । लेकिन वे सभी बहुत समान हैं, इसलिए मैं इस पर अधिक विस्तार से ध्यान नहीं दूंगा।

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)) // <= { .... } .... } 

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

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

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 कोड में पाए गए थे।उत्साही और बस दिलचस्पी है, मैं इस (या किसी अन्य) परियोजना के कोड में त्रुटियों का एक स्वतंत्र अध्ययन करने का सुझाव देता हूं। मैं शायद कुछ और दिलचस्प याद कर सकता था। ऐसा करने के लिए, बस पीवीएस-स्टूडियो डाउनलोड और इंस्टॉल करें ।

पढ़ने के लिए धन्यवाद। एक कोडलेस कोड!

यदि आप इस लेख को अंग्रेजी बोलने वाले दर्शकों के साथ साझा करना चाहते हैं, तो कृपया अनुवाद के लिंक का उपयोग करें: सर्गेई ख्रेनोव। एज़्योर पॉवरशेल: ज्यादातर हानिरहित ।