Caffeinated Wisdom

Inspired by what Jeff Fritz ( https://www.twitch.tv/csharpfritz ) said on .net rocks ( https://www.dotnetrocks.com/?show=1575 ), I decided to try doing a very small F# tutorial using Twitch: https://www.twitch.tv/videos/716521139

I ran into an issue with debugging a Workflow Foundation workflow by using breakpoints in the designer in Visual Studio 2019. The breakpoints in the designer were not being hit when running the console workflow program in debug mode.  A question posted by another member of the community at https://developercommunity.visualstudio.com/content/problem/846593/not-able-to-debug-windows-workflow-designer.html led me to another link at https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/retargeting/4.7.2-4.8#windows-workflow-foundation-wf .  In that last page, at the bottom, under the "Workflow XAML checksums for symbols changed from SHA1 to SHA256", I found the piece of configuration code to add to my app.config file in the console workflow VS project. The following is the full configuration of my project that allowed VS to pause at the designer breakpoints: <?xml version="1.0" encoding="utf-8" ?> <configuration>     <startup>  

I was getting the following error from iSS when testing locally a web api that requires ssl client certificates: 403.16  The client certificate used for this request is not trusted by the Web server One way to troubleshoot is to use the certutil tool that comes with Windows. There is a verify switch that you can use to verify the public portion of the client certificate: certutil -f -urlfetch -verify "public client cert.cer" The tool will show any errors encountered when validating the cert, such as a failure to lookup the revocation list (CRL) of the issuer. You can also capture the details of the client certificate, like the subject name, issuer and serial number, by adding custom fields to your IIS log. Instructions are here and the fields are under "Server Variables".  The specific issue I was having, however, is described in the answer to  https://stackoverflow.com/questions/26247462/http-error-403-16-client-certificate-trust-issue  . I had a Trusted Root cert

When I added an SFTP create file action to my Power Automate flow ( https://flow.microsoft.com ) , I got the following error in the action step, within the designer: "Test connection failed" To troubleshoot the Power Automate connection, I had to: go the Power Automate portal then "Data"->"Connections"  the sftp connection was there, I clicked on the ellipsis, and entered the connection info It turns out, that screen provides more details about the connection error. In my case, it was complaining that "SSH host key finger-print xxx format is not supported. It must be in 'MD5' format". I had provided the sha fingerprint that WinScp shows. Instead, I needed to use the MD5 version of the fingerprint. To get that, I had to run in command line (I was in a folder that had openssh in it): ssh -o FingerprintHash=md5 mysftpsite.com To get the fingerprint in MD5 format. I took the string (without the "MD5:" part of the string) and put

Unfortunately, I have not been able to make the CoreWf library ( https://github.com/UiPath-Open/corewf ) run on an Azure v2 or v3 functions. Something about the Azure function runtime not able to fins the dependencies like System.Xaml or System.CodeDom. However, Azure v1 functions (which run on .net 4.6.1) have no problems running a Workflow created using the Workflow Designer in Visual Studio. A sample of such function is in  https://github.com/jptarqu/WorkflowForCorePlayground/tree/master/src/AzureSamples  .  I did run into an issue creating from Visual Studio the Function App Service with runtime version of "1". I was seeing "runtime: error" in the portal's overview page for the app service. To work around that issue, I created the function app service inside the Azure Portal and then changed it to version 1 inside the portal (the default is v3 and you cannot change it until the App Service is created).

Workflow Foundation is a great tool when designing workflows for .net. Unfortunately, just like WCF, that technology is not going to be ported to .net core. However, a company named UI Path ( https://www.uipath.com/ )  that heavily relies on Windows Workflow Foundation, has started an unofficial port to .net ( https://github.com/UiPath-Open/corewf ). In order to see how compatible would be the the new port with the current Windows Workflow for simple workflows, I created a playground project at   https://github.com/jptarqu/WorkflowForCorePlayground  . The Visual Studio solution contains two projects: WorkflowForCorePlayground  : a VB.net Windows Workflow project created using the VS template for .net 4.8.  CoreWfSample  : a .net core console app that runs a cleaned version of the same xaml that project #1 has. The idea is to explore the possibility of still having business users design the workflow using the regular .net framework 4.8 beautiful and easy-to-use designer, while