Myoddweb.com

If, like me, you have more than one Github account, (one for work and one private), then you might want to switch accounts when using Visual Studio

My private account does not have CoPilot, so it has a little fit when I try and open visual studio.

Now if you click on the link … it takes me to Github and, it doesn’t matter what I do, my credentials are not changed from my private account to my work account.

The solution is simply to force Github to forget about you

• Close Visual Studio
• Probably Close VS Code as well … not sure
• Go to %localappdata%\github-copilot, (your local app data folder, something like C:\Users\%USERNAME%\AppData\Local\github-copilot)
• Delete the files hosts.json and versions.json
• Make sure you are logged in the correct Github account, (with Edge or Chrome or whatever).
• Restart Visual Studio, you should get logged in auto-magically into your ‘correct’ github account, otherwise you can just login when prompted.

And that’s all, if you are not sure about deleting files you can just rename the folder “github-copilot” to something else, and if things go wrong just rename it back.

If you are not sure or comfortable with deleting, renaming and so on … don’t do it. … you probably should not be developing either in that case, but that’s another problem I guess.

Consider the following code …

In the code you would be forgiven for thinking that the function “This()” would be called from the derived class, but in fact it is called from the base class

This is because the derived class has been deleted by the time we call the base destructor.

Moral of the story, clean up what you need to cleanup in your derived class, ’cause the base class is not going to do it for you!

What is it for?

Strong naming basically helps to make sure that other assemblies can be 100% sure that they are using the correct assembly and they there has been no messing around

In reality, this not a 100% secure process, but it does help in most cases to add a certain amount of safeguard.

And in any case, a lot of applications require it, and if your app is not strong named, then they will not be able to use it.

How to add strong name to my assemblies

The process is fairly straight forward, (surprisingly so), and you don’t need to worry about Visual Studio until the end.

• On your system locate the file called sn.exe, (in my case, I had a few of them, the actual version does not matter, but I chose the latest one I have).
• Open a command line with Administrator privilege, (might not be required, but I don’t know how secure your system is).
• Navigate to the folder where that exe is located.

• Create a key … any key, just make sure you give it a name that matters to your application
  

• Now get the public key for your application
  sn -p "myassembly.snk" "pmyassembly.snk"
  I added the letter “P” in front of my strong name key … so I know it is the public key … but really, you can call it whatever you want.

• You might also want your public key as a string value
  sn -tp "pmyassembly.snk"

• Or you can be one of the cool kids and output to your clipboard
  sn -tp "pmyassembly.snk" |clip
  And then you can paste it where ever
• I really suggest that you move the file, (with a better name), to your directory
• Then fire up your visual studio project
  • Look for the properties
  • Select the signing tool
  • And check “sign the Assembly”

• Annoyingly enough, Visual Studio will move the file where it feels it should be, (next to the *.csproj), if you really want it somewhere else, just edit the *.csproj file and change the location yourself. Or don’t, whatever.
• Build it
• Ship it

What about my Unit tests?

If you have unit tests running and you are testing internal classes … then you will need to add the public key, (see above), to your InternalsVisibleTo( … )

At the end of the day, this is pretty much what consumers of your assembly will do.

What info must I share?

• Your *.snk file
• Your public key text value

Remember, this is just to verify the identity of your file, not to do some NSA proof securing of some sort.
You want to share the information so others can use it in their own projects.

More

• https://docs.microsoft.com/en-us/dotnet/standard/assembly/strong-named
• https://docs.microsoft.com/en-us/dotnet/framework/tools/sn-exe-strong-name-tool
• https://github.com/FFMG/myoddweb.directorywatcher
• https://github.com/FFMG/myoddweb.commandlineparser

We often ask people in interview to explain the solid principles and what they mean.

The other day I found a series that goes into details about the SOLID principles

• S- Single Responsibility Principle Explained Practically in C# (The S in SOLID)
• O – Open Closed Principle Explained Practically in C# (The O in SOLID)
• L – Liskov Substitution Principle Explained Practically in C# (The L in SOLID)
• I – Interface Segregation Principle Explained Practically in C# (The I in SOLID)
• D – Dependency Inversion Principle Explained Practically in C# (The D in SOLID)

Those are rather long videos, but they go into great details explaining the SOLID principle.

I like to use threads in my code, but the problem with threads is that sometimes you need to wait for them to finish.

In c++ it is very easy to do.

All the code above does is, start a thread, call the function my_function and passes the argument 1.
The t.join(); tells the main thread to wait until the thread is finished.

Now the problem is that t.join() could hang forever … and I would never know about it.

What I needed was something like join_until( 1000) where we either wait for the thread to finish or wait for 1000ms. What I needed was something similar to c# SpinUntil

In very simple terms all SpinUntil does is check a condition, (very often), and if it is true then return (true), but if a timeout happens then we return (false).
So in my case I would wait for the thread to complete, (yes I know, I know, you can’t easily tell if a std::thread is complete or not.

Enter Wait.SpinUntil …

Basically we will

1. Start a new thread
2. Check if the given condition is true
   1. If the condition is true, return true
   2. If the condition is false … continue.
3. Wait for a couple of nanoseconds for other threads to do their bit
4. Look how long we have been spinning
   1. If less than milliseconds go back to number 2
   2. If more than milliseconds, return false.

The code

This is a very simplified version of the code, you can find a working solution on my github page

So now the code above will wait for a couple of ms while running in the background and if the given condition is true we will get out and return true, otherwise we will return false after a while.

Possible issues

• For one thing, the condition() function could hang, it is up to the caller to make sure this never happens.
• The condition() function could take a rather long time to execute … it is up to the caller to make sure this never happens

In other words, don’t stuff things up in your condition() function.

Why?

While it is easy(ish) enough to add google test using various packages, you might want to add it directly to your project, (to debug your tests and so on).

I also found that packages are not always as often as you might want, so it might be because you need a new feature or something added to your test.

Before we start

– I am using Visual Studio 2019, but it should work fine with 2017 and even 2015
– I am using the latest Google Test (v1.10 at the time of writing this, but the principle is the same for almost all versions and should work fine for a few versions.

Getting started

• Go to Google test on Github and get the latest release, make sure you get the ‘source code’
• Don’t get it from anywhere else, you don’t know what has been changed and who changed it!
• Remember that google test is written to a test application, not your main application!
• Create a new console application, (File > New > Project …) and select “Console App”

Now add Google Test

• Download the latest release of Google test and extract it in your project folder, (of course create a sub folder of sort).

• In your project, create a new ‘folder’, I normally prefer to have it mirror what it looks like in my actual windows source code directory, but you could call it whatever you want, (like I did below).

• Right-click on the ‘src’ folder and select “Add > Existing Items…”
• Navigate to the folder you extracted, and find the ‘googletest > src’ folder

• And then select ‘gtest_main.cc’ and ‘gtest-all.cc’, nothing else.

• Finally, right-click your project and select “properties” and edit the “Additional Include Directories”

• Add the directory relative to the location of your solution
  You could enter the full path if you want, (but that … blah), or you could use macros …
  Either way, make sure that the path is valid.

• Make sure that the changes you make apply to all your build configuration.
  In the screenshot above I have x64 and Release but make sure that you choose all the configurations you will be using.
• Compile your code … nothing funny should happen, (’cause you did nothing really).
  If you get an error, double check your paths and permissions.

Write and run a test

Last but not least, write a very simple test in your main and run a test

You do the rest

Now that a simple test is running, you can start creating tests for your own project.

Example?

Have a look at my directory watcher project and see my own tests.

As an aside, I am alway looking for comments, reviews and so on, please have a look at the project and comment!

As mentioned in my previous post, to get a ‘proper’ parallel foreach that is async is a bit of a pain

So the solution is to write a true async function

And you can call it …

Of course, you can refine it by adding check for tokens that cannot be cancelled as well as empty sources

First prize you must make sure that the body of the ForEach takes in the token and cancels cleanly otherwise this will jump out with thread left up in the air… but at least it will get out.

Edit: As someone pointed out to me on StackOverflow there are a couple of subtle ways I can improve my implementation … so I added them here

Bad things, bad things happen … explosions, tears … and maybe more

In the example above, the code will explode because of the exception.
So obviously we will add a try catch block…

And that will work, (of course)

But what if we want to run an async function in parallel … then what do we do?

In the case above you fire tasks, but don’t really wait for them to complete.
The async and await might give you the feeling that you are doing something truly in parallel … but you are not
Because Parallel.ForEach has no overload accepting a Func<Task>, it accepts only Action delegates.

The easy way out is to use Task as they were intended

Now obviously this is ugly code, but you get the idea … run all the tasks in parallel and wait for them all to finish.

Once they are all done, you can throw an aggregation of errors…. if there are any

Have a look at the code on my github page for more information/sample

Sometimes when trying to pull/push to a git repo, (on my own server or github), I get something like

fatal: Authentication failed for ‘https://….'”

Now the problem is that I don’t even get asked for a username and password … sounds a bit stupid if you ask me.

On Windows 10:

• Press Start, (the windows key)
• Start typing “Credential Manager” or look for it in the control panel
  

• Then select the Windows Credentials
• Look for whatever website is the one that has your credentials
  Usually something like git:http://...
• Remove the entry or edit it.
  If you remove it you will be asked for the credentials again.

I often wonder what the fastest lock is in C#.

If course they all have their own pros and cons, but when it comes to raw speed, what is the fastest lock.

We have a couple of options, but the common ones are

• Lock object
• Semaphore
• Mutex
• Read writer lock
  • Read
  • Write

The test was to add 10 million random numbers and test the various locks.

As this is not a multi threaded application, the waiting for the lock is imaterial here, we are only testing getting the lock.

In other words, this is an ideal scenario, you are not waiting for any lock, you are simply getting it.

Obviously not getting any locks is faster, followed by both the ReaderWriterLockSlim, (read lock and write lock), then the SemaphoreSlim and the Mutex was, by far, the worse of them all.

• The ReaderWriterLockSlim is slower because extra work is spent looking for re-entry as well as using a SpinLock
• The SemaphoreSlim is even slower because we do a SpinWait and wait other threads to release the lock, (or locks as we could have more than one).
• The mutex class is slower still because it puts the thread to sleep until it has access to the handle, and then wakes it up again.

You have a look at the code on my github page.