PowerShell to check whether the .Net assembly is compiled into debug or release

Often as part of reviews we need to check whether the application deployed is compiled in release mode or not. Most of the CI/CD tools compile in release mode only. But if some has modified any assemblies post deployment manually and missed to compile in release mode, it is worth checking the assemblies.

It is easy to run PowerShell in productio environments than running a tool to check. Running an external exe is often makes discomfort to the production support guys. Essentially running a PowerShell script and custom tool are same from technical perspective. But since the PowerShell source is plain text and production support guys are familiar with PowerShell, they normally allow.

This is not my creation. Got from somewhere in the internet and posting here so I can use it next time.

---

Get-ChildItem -Filter *.dll -Recurse |

    ForEach-Object {

        try {
         $Assembly = [Reflection.Assembly]::LoadFile($_.FullName);
         $type = [System.Type]::GetType("System.Diagnostics.DebuggableAttribute");
         $debugAttribute = $Assembly.GetCustomAttributes($type,$false);
         If ($debugAttribute.count -Eq 0) {
            "{$_.Name} :Release"
         }
         ElseIf ($debugAttribute[0].IsJITOptimizerDisabled -eq $false) {
            "{$_.Name} :Release"
         }
         Else {
            "{$_.Name}  :Debug"
            }
        } catch{ "{$_.FullName} ***ERROR*** Error when loading assembly: " }                 

    }

---

Make sure the PowerShell is in the right folder context so that it can get the files using *.dll filter.

A .Net version is available in Hanselman's blog.

Azure @ Enterprise - What the *** is https://neu-breeziest-in.cloudapp.net/

The *** can be read as 'Url' or 'Uri'. Don't get confused with the * which is often used for replacement of 4 letter English words.

Background

It was late night debugging with Microsoft teams on a critical support ticket. Critical support ticket means there will be Microsoft team engaged 24x7 till the issue is resolved. Their support engineers keep on changing every 8 hours. To my understanding its costly but we are at enterprise where things happen differently as money doesn't seems a factor.

The issue was related to VSO(Visual Studio Online) driven VSTS load testing tool showing high number than the IIS web server logs.

After giving logs and long hours of waiting time , Microsoft came up with interesting discovery that our web application hosted in IIS which is under the load test is making lot of calls to the below URL. The calls are failing and due to making lot of connections the ports in web server is exhausted hence the issue?

https://neu-breeziest-in.cloudapp.net/

Come on Microsoft. The issue is the different.Numbers shown in IIS logs time-taken v/s the request time shown in the VSTS load testing result. Anything can happen in the web server, but as long as the VSTS tool can show matching time with IIS, we are good. Then we can start baseline performance test and optimizations.

What is actually https://neu-breeziest-in.cloudapp.net/

However we have to answer the question from Microsoft regardless its relevant in the situation. So just tried to ping the domain. Attached the screenshot.

Yes it is Azure AppInsight calls going out from the web application. It uses default configuration of AppInsight SDK when its installed via nuget package manager. It has sampling settings of 5 entries per second.

https://docs.microsoft.com/en-us/azure/azure-monitor/app/ip-addresses

We continued the tests after disabling AppInsights but still the problem persisted. The problem of VSO load tests showing high request execution time where IIS time-taken field shows very low. That issue is still going on even during the time of writing this post. More on that will be posted once the issue is settled.

Are there more of this kind

When we googled the URL we could see very less references. One below.
http://steveloughran.blogspot.com/2017/02/why-https-is-so-essential-and-auto.html

We further understood that the 'neu' in the below url is for North EU Azure data center.
https://neu-breeziest-in.cloudapp.net/

So there will be another urls pointing to other data centers. If you came across this kind of interesting  URLs to where outgoing communications is going from your application, keep in mind its the fun from Microsoft. 

The important recommendation is, we should be opening communication ports to specific IPs based on Azure documentation than entire cloudapp.net.