Blog posts by Johan Antila

Blog posts by Johan Antila2024-03-06T20:11:50.0000000Zhttps://world.optimizely.com/blogs/johan-antila/ Optimizely World When Visual Studio Code Metrics failVisual Studio Code Metrics- that won't show up. At Optimizely Expert Services, we are often times asked to do code reviews and assessments of customer solutions and these typically involve using static code analysers and reading code bases. One good tool for finding complex parts of a solution is the Code Metrics tool in Visual Studio that gives you an indication of hot spots in the code base. For example, it can show you the complexity of the code, generate something it calls Maintainability Index, It can list lines of code and display what of this is executable code, the latter is especially handy for projects and namespaces where you have your views. Unfortunately, there's been a few times where I have happened upon a bug in the Visual Studio Roslyn engine that stops the Code Metrics from rendering in the Code Metrics Window. Instead of listing the namespaces and calculated metrics, the window is just blank. In vain, I have struggled to find the reason behind this and to fix it for the specific solution but I have come up empty handed. When it happened again this time and I went searching for a solution, one of the pages I came across mentioned that there was an automated process calculating the metrics and this led me to investigate if there was a command line tool to do this and perhaps, this would work when the built one wouldn't. It turns out that indeed, Microsoft has created such a tool called <a href="https://github.com/dotnet/roslyn-analyzers">Microsoft.CodeAnalysis.NetAnalyzers</a> You can either add a package reference to your project to be able to target it using msbuild or compile a stand alone command line tool called to do this calculation in a command shell. As the nuget package solution didn't work for me, I opted for the latter solution with a command line tool and followed <a href="https://learn.microsoft.com/en-us/visualstudio/code-quality/how-to-generate-code-metrics-data?view=vs-2019">this guide.</a> With the tool compiled, start up a Visual Studio Command Prompt, and run it to generate an xml file:  <pre>metrics.exe /p:project myproject.csproj /out:report.xml</pre> This generates an XML file with the code metrics in it but that's not the Excel output that the built in tool generates. Now what? Well you have to parse the xml file some way so I opted to parse it to json and iterate over it using a serialized version of the file. <a href="https://github.com/johan-antila-episerver/ParseMetricsXml">I wrote a small tool to do just that</a>, it takes the xml file and outputs a csv file that you can import in Excel. You can find it over at <a href="https://github.com/johan-antila-episerver/ParseMetricsXml">GitHub.</a> One final note, to be able to parse the json in a compile time fashion, you need to catch the json content after it has been parsed from XML, copy it and use Visual Studio -> Edit -> Paste Special -> Paste JSON as classes to get classes that you now can use in the code.2024-03-06T20:11:50.0000000Z

Blog post

Azure DevOps and failing VSTest taskSometime during the summer, our Test task for a customers Azure Devops CI/CD environment stopped working for no apparent reason and as it had been unchanged for more than a year, the problem looked like it would be related to the Azure Devops environment itself. Checking build logs, we could conclude that Microsoft did an update to the default build runner used in Azure DevOps sometime in August or perhaps late July, 2022 (We lack builds from just before so we don't know the exact date) and it included a later version of the VSTest task that had a different behaviour than the previous one. It turned out that our test task included a lot of dlls targeted for different frameworks that were not actual tests that should not have been included but this selection of dlls hadn't changed, it was always the same and it had always picked up a lot more test dlls than it should have done - all with different targets - but since that was never a problem with the previous runner, we didn't pay attention to this. Where the old version would ignore this situation, the newer version of the VSTask returned a fail when it picked up dlls from different framework targets, something it does not support, thus failing the build even though the tests it actually managed to run all passed. The solution to this is to specify a less exclusive search pattern than the default one that you get if you define the test task in your yaml file like this: <pre>- task: VSTest@2   inputs:     platform: '$(buildPlatform)'     configuration: '$(buildConfiguration)'</pre> <pre>(Not specifying wildcard pattern defaults to this search pattern: **\*test*.dll,!**\*TestAdapter.dll,!**\obj\**)</pre> In my build, this would include all these files: <pre>vstest.console.exe "D:\a\1\s\Customer.Web\bin\EPiServer.Marketing.Testing.Core.dll" "D:\a\1\s\Customer.Web\bin\EPiServer.Marketing.Testing.Dal.dll" "D:\a\1\s\Customer.Web\bin\EPiServer.Marketing.Testing.Web.dll" "D:\a\1\s\Tests\Tests.Customer.Framework\bin\Release\Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.Interface.dll" "D:\a\1\s\packages\MSTest.TestAdapter.2.1.2\build\_common\pl\Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.resources.dll" "D:\a\1\s\packages\MSTest.TestAdapter.2.1.2\build\_common\pl\Microsoft.VisualStudio.TestPlatform.TestFramework.resources.dll" "D:\a\1\s\packages\MSTest.TestAdapter.2.1.2\build\_common\pt\Microsoft.VisualStudio.TestPlatform.MSTest.TestAdapter.resources.dll" "D:\a\1\s\packages\MSTest.TestAdapter.2.1.2\build\_common\pt\Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.resources.dll" "D:\a\1\s\packages\MSTest.TestAdapter.2.1.2\build\_common\pt\Microsoft.VisualStudio.TestPlatform.TestFramework.resources.dll" "D:\a\1\s\packages\MSTest.TestAdapter.2.1.2\build\_common\ru\Microsoft.VisualStudio.TestPlatform.MSTest.TestAdapter.resources.dll" "D:\a\1\s\packages\MSTest.TestAdapter.2.1.2\build\_common\ru\Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.resources.dll" "D:\a\1\s\packages\MSTest.TestAdapter.2.1.2\build\_common\ru\Microsoft.VisualStudio.TestPlatform.TestFramework.resources.dll" "D:\a\1\s\packages\MSTest.TestAdapter.2.1.2\build\_common\tr\Microsoft.VisualStudio.TestPlatform.MSTest.TestAdapter.resources.dll" "D:\a\1\s\packages\MSTest.TestAdapter.2.1.2\build\_common\tr\Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.resources.dll" "D:\a\1\s\packages\MSTest.TestAdapter.2.1.2\build\_common\tr\Microsoft.VisualStudio.TestPlatform.TestFramework.resources.dll" "D:\a\1\s\packages\MSTest.TestAdapter.2.1.2\build\_common\zh-Hans\Microsoft.VisualStudio.TestPlatform.MSTest.TestAdapter.resources.dll" "D:\a\1\s\packages\MSTest.TestAdapter.2.1.2\build\_common\zh-Hans\Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.resources.dll" "D:\a\1\s\packages\MSTest.TestAdapter.2.1.2\build\_common\zh-Hans\Microsoft.VisualStudio.TestPlatform.TestFramework.resources.dll" "D:\a\1\s\packages\MSTest.TestAdapter.2.1.2\build\_common\zh-Hant\Microsoft.VisualStudio.TestPlatform.MSTest.TestAdapter.resources.dll" "D:\a\1\s\packages\MSTest.TestAdapter.2.1.2\build\_common\zh-Hant\Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.resources.dll" "D:\a\1\s\packages\MSTest.TestAdapter.2.1.2\build\_common\zh-Hant\Microsoft.VisualStudio.TestPlatform.TestFramework.resources.dll" "D:\a\1\s\packages\MSTest.TestAdapter.2.1.2\build\netcoreapp1.0\Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.dll" "D:\a\1\s\packages\MSTest.TestAdapter.2.1.2\build\uap10.0\Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.dll" "D:\a\1\s\packages\MSTest.TestFramework.2.1.2\lib\net45\Microsoft.VisualStudio.TestPlatform.TestFramework.Extensions.dll" "D:\a\1\s\packages\MSTest.TestFramework.2.1.2\lib\net45\Microsoft.VisualStudio.TestPlatform.TestFramework.dll" "D:\a\1\s\packages\MSTest.TestFramework.2.1.2\lib\netstandard1.0\Microsoft.VisualStudio.TestPlatform.TestFramework.Extensions.dll" "D:\a\1\s\packages\MSTest.TestFramework.2.1.2\lib\netstandard1.0\Microsoft.VisualStudio.TestPlatform.TestFramework.dll" "D:\a\1\s\packages\MSTest.TestFramework.2.1.2\lib\uap10.0\Microsoft.VisualStudio.TestPlatform.TestFramework.Extensions.dll" "D:\a\1\s\packages\MSTest.TestFramework.2.1.2\lib\uap10.0\Microsoft.VisualStudio.TestPlatform.TestFramework.dll"</pre> After changing the way test assemblies are found like this: <pre>- task: <a href="mailto:VSTest@2">VSTest@2</a>   inputs:     testSelector: 'testAssemblies'     testAssemblyVer2: |     **\tests.customer*.dll     searchFolder: '$(System.DefaultWorkingDirectory)'      It now includes only the relevant assemblies: </pre> <pre>vstest.console.exe "D:\a\1\s\Tests\Tests.Customer.Framework\bin\Release\Tests.Customer.Framework.dll" "D:\a\1\s\Tests\Tests.Customer.Framework\obj\Release\Tests.Customer.Framework.dll" "D:\a\1\s\Tests\Tests.Customer.Web\bin\Release\Tests.Customer.Web.dll" "D:\a\1\s\Tests\Tests.Customer.Web\obj\Release\Tests.Customer.Web.dll" </pre> And with this, the test now passes. Succes! In other words, make sure you have a coherent naming scheme for your tests that is easy to pick up with a wildcard pattern and make sure your test task only picks up these specific dlls. You can see the output of the VSTest task in the pipeline in Azure Devops to detrmine what dlls it's trying to probe for tests. 2022-09-16T11:07:31.0000000Z

Blog post

Scripted testing of IIS URL Rewrite rulesOn most websites today you are likely to need to rewrite urls to match a specific requirement such as the typical SEO rules where you need urls to all end with a trailing slash and be all lowercase to prevent duplicate content in the search engines or add a few hard coded redirects for old discontinued sites. While these rules by themselves are easy enough to test, as soon as you start creating a few more rules and they contain host names, you will get a bit of a challenge to test these locally. While it is possible to test the rules locally in the IIS Administration tool, this is only an atomic test of the single rule and not a test of the entire redirect pipeline so if you introduce one bad rule, you can't tell if it breaks the other redirects unless you request it with a browser through IIS and with a lot of urls, this becomes increasingly impractical and in the scenario where you yourself aren't handling the go-live and you haven't been able to test the rules locally, it creates the need to write these same rules as a human readable script for whoever is doing the deploy/rollback to test after applying the change. If only there was a way to script this. Well there is. Using <a href="https://nodejs.org/en/">nodejs</a> with <a href="https://github.com/GoogleChrome/puppeteer">puppeteer</a>, you can easily create a test script in which you define all your urls you want to test and see if they are redirecting as expected. First you need to install nodejs <a href="https://nodejs.org/en/"></a> if you haven't already done that, then in a console window, <a href="https://developers.google.com/web/tools/puppeteer/get-started">install puppeteer</a> , a module to programmatically control googles <a href="https://developers.google.com/web/updates/2017/04/headless-chrome">Headless Chrome</a>. <code>npm install puppeteer</code> With puppeteer you can do all sorts of things with automatic testing and we are going to use it in a pretty simple way, let it navigate to a url and see what url it ends up on and test if we were expecting this url. The nice thing here is that we're testing what a browser would actually do after it has completed all the redirects, even ones you've written in code for redirecting users based on geo-ip for instance and if you have a redirect loop here, you will get an error. Now you need to make sure you have all the redirect rules in place for production in your local dev environment, ie, in web.config and if you're not comfortable with having these rules permanently in your development environment, you could set up a config transformation and a custom msbuild target that will create the web.config with local settings and the redirects included. If you're not familiar with how to do this, this is how I generate config files when I need to see how they would look when deployed to the Episerver DXC that uses <a href="/link/64d168381a354d788e9897250f044b57.aspx">config transformations</a>: <code> <Target Name="DXCConfigs"></code> <code>  <TransformXml Source="web.config" Transform="Web.integration.config" Destination="web.integration.out.dxc.config" /></code> <code>  <TransformXml Source="web.integration.out.dxc.config" Transform="web.preproduction.config" Destination="web.preproduction.out.dxc.config" /></code> <code>  <TransformXml Source="web.preproduction.out.dxc.config" Transform="web.production.config" Destination="web.production.out.dxc.config" /></code> <code></Target></code> and you run it from the command-line like this: <code>msbuild /T:DXCConfigs</code> After this is done, you need to make sure you local IIS listens to all domains you are going to test. The easiest way to accomplish this is to just add a wildcard mapping but if this is not possible for you, add them one by one under Edit Bindings in IIS. Note that if the redirect rules include upgrading the connection to https, you need to add a self signed certificate and add mappings in IIS for this too. Now edit the hosts file and add your hosts <code>127.0.0.1 episerver.com</code> <code>127.0.0.1 www.episerver.com</code> <code>127.0.0.1 ektron.com</code> <code>127.0.0.1 www.episerver.se</code> One thing to note is that if you are testing redirects with HTTPS, you need Chromium to ignore SSL certificate warnings for your local certs for the script to work, this is done by launching puppeteer with the ignoreHTTPSErrors flag set to true as can be seen in the script below. My script looks like this: <code>/*</code> <code>Test redirects</code> <code>*/</code> <code>const puppeteer = require('puppeteer');</code> <code>(async () => {</code> <code>  async function testurl( fromurl, tourl) {</code> <code>  try {</code> <code>     await page.goto(fromurl, {</code> <code>     waitUntil: 'networkidle2'</code> <code>   });</code> <code>   if (await page.url() === tourl) {</code> <code>     await console.log("Success: ", page.url());</code> <code>     return true;</code> <code>   } else {</code> <code>     console.log("*** Fail. " + fromurl + " Got: ", page.url() + " expected: " + tourl);</code> <code>     return false;</code> <code>   }</code> <code>  } catch (error) {</code> <code>   console.log("*** Error " + fromurl + " " + error);</code> <code>   }</code> <code>  }</code> <code>  // set up puppeteer to ignore HTTPS errors so it won't bomb on your self-signed certificates</code> <code>  const browser = await puppeteer.launch({</code> <code>    ignoreHTTPSErrors: true</code> <code>  });</code> <code>  const page = await browser.newPage();</code> <code>  await testurl('http://episerver.se', 'https://www.episerver.se/');</code> <code>  await testurl('http://ektron.com/', 'https://www.episerver.com/');</code> <code>  await testurl('https://www.EPiServer.COM/', 'https://www.episerver.com/');</code> <code>  await testurl('https://www.episerver.com/ascend-conference/ascend-2019', 'https://www.episerver.com/ascend-conference/ascend-2019/');</code> <code>  await testurl('http://www.episerver.no/dxc', 'https://www.episerver.no/produkter/funksjoner/plattform-som-en-tjeneste/');</code> <code>  await browser.close();</code> <code>  })();</code> I only used my script to manually validate that the rules I introduced didn't break any of the other redirects (it turned out they did), especially the ones I had in the <a href="https://github.com/Geta/404handler">Geta 404 handler</a>, but if you need to do this in a more unittest-like fashion, see <a href="https://developers.google.com/web/updates/2017/06/headless-karma-mocha-chai">this post</a> for inspiration on how to use an assertion framework with Headless Chrome. Finally, when you are sure you didn't break anything with your new rules and they were deployed into production, just comment out the entries in the hosts file and run the script again to test the rules in production if you'd like to.2019-09-04T13:27:31.0000000Z

Blog post