Category Archives: software

how to use messenger and facebook without the app

Leave a reply

Facebook is probably the worst social media company out there, so it makes sense you don’t want their apps on your phone. But unfortunately your less privacy concerned friends are all gleefully using Facebook and Messenger and you don’t want to miss out.

I understand your pain. Here’s a simple guide to still use Zuck’s book on your phone, without the dreaded apps.

Step 1: get a new browser app

We’re going to use the mobile site, which works quite well. To separate all the Facebook traffic from our regular surfing habits and keep Zuck from snooping on us, we’ll use a completely different browser app.

Head over to the Google Play Store and search for “browser“. You’ll see a big list of browser apps, so you just have to pick one you’re not currently using. You are most likely using Chrome as your main browser, or the Samsung browser if you have a Samsung phone, so you can go for Firefox or the DuckDuckGo Privacy Browser as your alternative. Both are good browsers, and I’ve used them both for faking the Facebook. I even use Firefox as my main browser.

The Android Play Store results when looking for a new browser.

Step 2: open your newly acquired browser app, and surf to facebook.com.

After you log in, you’ll be able to use the mobile site pretty much like the app. Now, since this is a separate browser, you just leave your Facebook tab open. Next time you start your dedicated browser app for Facebook, you’ll be logged in already. Easy-peasy. Just don’t use this browser for anything else. If you do, Zuck will be able to follow you around on every site that has anything enabled related to Facebook or Instagram.

Step 3: set up messenger.

Messenger sucks because they want to force you to install the app when you use the mobile site to check your messages. There is a way around this though.
Messenger still works on the desktop site aka your PC/laptop right? So we just have to tell Facebook we’re using that from our phone.
You can do this by going to facebook.com in a second tab on your new browser. Now, you click the 3 dot-menu in the menu bar and activate the “Desktopsite” checkbox. The page will refresh and look pretty much the same, but now it thinks you’re visiting it from a desktop PC. Now open the Facebook hamburger menu, choose Messenger and voilà, there you have all your messages and contacts.

The trick is to leave this second tab open on your phone as well, so you have quick access to your messages whenever you like. After not using it for a while, you might end up with a message telling you to install the app again. This is because the tab refreshed and is back in mobile-mode. When this happens, just go back into the 3-dot menu of your browser and check the “Desktopsite” checkbox again. After reloading the page, you’re set again.
A minor inconvenience for the added privacy of not having Zuck’s spy-apps on your phone if you ask me. ;)

An Android app icon showing Fakebook instead of Facebook. Funny, isn't it?

Step 4: change the icon.

If you want to get fancy, now is the time to long-press the icon of your now dedicated Facebook-browser app and change the icon to… the Facebook icon perhaps? I also change the name to something more appropriate, like Fakebook for example.

Step 5: convince your friends to not use Facebook, WhatsApp or Instagram.

Just kidding.
Maybe.

.net core: could not load file or assembly runtime error

Leave a reply

Shortly after posting about my tips to fix broken builds, I was in for another bug hunt that took a few hours to resolve. This time it wasn’t the build itself that failed, but the package that came out of it. For some reason, the application crashed instantly on a missing DLL error you know and hate in .NET.
Usually it means a Nuget package conflict. Cleaning the build sometimes helps, but not in this case. We are talking about system DLL’s here, so you know you’re in trouble when that happens.

I was getting the following exception at runtime on a .NET Core app. It wasn’t always the same DLL. But every time it was a system DLL like System.Collections, System.Collection.Generic, System.Linq, etc.

Unhandled exception. System.IO.FileLoadException: Could not load file or assembly 'System.Collections, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The located assembly's manifest definition does not match the assembly reference. (0x80131040)
File name: 'System.Collections, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
   at Microsoft.Extensions.DependencyInjection.ServiceCollection..ctor()

When checking the package files, the wrong version of the DLL was in the output, compared to the version number I was seeing in the solution, so the error message was correct. The problem was, why does the build pick the wrong DLL version? My local build output was fine however, so that just adds to the mystery.

The special bit about this project is that it also used a .NET Framework DLL. It was doing some .NET Standard magic in the build.

The symptoms

  • The project has a mix of .NET Core / .NET Standard / .NET Framework projects or Nuget packages.
  • You are building a self contained application (so all DLL’s are copied in the output folder).
  • Seemingly random 0x80131040 errors when I try to run my deployed .NET Core app on system DLL’s.
  • Different builds give errors on different DLL’s, but they are always system DLL’s.
  • A local dotnet publish works, but the output from the build server doesn’t run.

The fix

The fix turned out to be stupefyingly simple. I was build the .sln file for my project in the CI pipeline, instead of the .csproj file for the console application itself.
Apparently things go wrong at build time and the wrong DLL’s are copied into your output folder, giving you the exceptions above on startup.
The reason why the same dotnet publish command works locally is probably because I have version 5 of the dotnet tool on my local machine, due to Visual Studio. On the build server version 3.1 is installed, from the 3.1 SDK. My guess is that the 3.1 version handles mixed solutions differently than the dotnet 5 version.

tips on fixing a broken build

Leave a reply

When builds break on the build server, it can be hard to figure out what the problem is. I’ve been doing this a lot of times, and so here’s a collection of tips that can help you in fixing that weird error that keeps breaking the build. Build systems are pretty similar, so whether you’re using TeamCity, Azure Devops, Gitlab, Jenkins, Circle CI or whatever, these should pretty much work everywhere.

Make sure it builds locally.

This has to be the “Did you try turning it on and off again?” of build fixing. Sometimes that build really is broken. A file might not have been checked in, or a merge might have gone wrong, but what you have on your local machine, might not be what’s in source control.
Get a clean copy of your repo in a separate folder, and build that to check if it builds OK. At least you’ll be 100% sure it’s nothing trivial before you start your investigation.

Try a clean build.

Another “try turning it on and off again” tip, I guess. On most build servers, you can opt to run a clean build. This means the agent will set up a fresh checkout folder for the new build. This way you make sure no leftovers from a previous build are causing the problem. Sometimes things go wrong with source control and getting the latest version, messing with your build. This also fixes that issue.

Does it fail everywhere?

Sometimes build agents are not installed in exactly the same way, and builds might break on a single or a few build agents only. This is good. Now you know you can always get a build on a good agent, so you aren’t stuck when you want to produce some build artifacts, and you know there’s something on that machine that’s not quite right where it’s failing.
The error will usually give you a clue on what’s missing, but most of the time you’ll only understand why after you resolved the issue. Ah, the joys of software development.
My tip here is to compare the machines and see what build tools are missing or different from the one where it does work. Make sure your SDK and build tool versions are the same, and can be found. Check your shell versions, like PowerShell and if they are running in x32 or x64 mode, and if all PS modules are installed in the mode you’re using.
If you have an automated way to quickly produce a build agent, you might want to ditch the failing one, in favor of a brand new one if your build works there.

Check the logs.

It sounds trivial, but the log files of your build server contain a lot of details you’re not looking at when things are working. Now that things are broken, it’s time to dig in and see if you can find a few clues. Most build systems also have settings to change how detailed those logs are. Setting this to verbose can be what you need to find that final clue to solve the puzzle.

Get into the machine.

When things should work, but appear broken on the build server, you’ll sometimes have to dial into the build agent and see what things look like in there. Paths might not be what is expected, files might actually be missing, and tools might be different. There you can open a shell, check if anything is missing, check if build tools are available, or try and run the same command that’s failing yourself. This doesn’t always work as build systems sometimes wrap your SDK calls, and you’re not always sure you’re running the same statement, but it might give you a hint of what’s going wrong anyway.
Look around on the machine, and you might find the problem. Can’t access the machine? Try the next tip.

Get into the machine, without getting into the machine.

You might not be able to access the build agent itself. Pesky admins, or it might even be a cloud machine you don’t own. Luckily you can edit the build itself right? In most cases, you can run some arbitrary shell commands as a build step for whatever fancy stuff that isn’t covered by default.
Well, nothing is stopping you from running an ls or type nuget.config command to find out what is really happening during your build. The output of those commands will normally appear in your build logs. You might have to check the more detailed full log files, but it should be there. This can be a tedious process, but it saved my butt a few times when things didn’t work for an at the time unknown reason.

wake up Windows automatically using a scheduled task

Leave a reply

This seems easy at first, but it turns out to be a lot harder than expected, due to various OS and power settings that get in the way. The idea is simple: you want to have your Windows 10 machine start up at a specific time using a task set in the task scheduler.

When you create a new task in the Task Scheduler, there’s a setting for this, so it looks so easy. It’s on the conditions tab. You activate the option to wake the computer to execute your task, and you’re done. Right? Well, if you’re really lucky that might work straight out of the box.
In case it doesn’t work, here are some things you can fiddle with to try and get it going.

  1. Create a wake-up tasks that doesn’t really do anything. Just run a command like this:
    cmd /c echo %date%
    For a more detailed guide on how to set up a task and the wake timers check this excellent article.
  2. Create a second task that does what you want it to do in a batch script but 10 minutes later than the first. That gives your computer ample time to start up, install any potential updates, or do whatever it sometimes does that takes so damn long.
  3. Deactivate Fast Startup. It messes with your hibernation mode and causes it not to startup again afterwards.
  4. Always hibernate your machine. If you just do a plain shutdown it doesn’t seem to automatically start up again. You can do this with the command below. This is also handy if you want to shut your machine down again, after your task has finished:
    shutdown /h
  5. Enable wake timers in your Power Options advanced settings. See the link below for instructions.
  6. For laptops make sure your Power Options are configured correctly. Mind closing the lid in that case. A closed lid will prevent the laptop from starting up in my case for example. Laptops will also not startup when they are running on the battery by default.
  7. Reboot your machine after fiddling with these settings if it still doesn’t work. This makes sure your settings stick.
  8. If you tried everything and it still doesn’t work, check your BIOS settings and see if there might be a power option in there that might prevent it from starting up automatically.

Give your machine a few minutes if you’re testing this. Yes, it’s annoying to wait, but if you set it too fast, it might not be powered down fast enough to be able to start up again, and miss the timer. That way you won’t be able to tell if it’s actually working.

Hopefully you can now use your desktop or laptop to run some nightly scheduled jobs, without having to have a dedicated always-on machine around. Saves you time and money on power consumption, hardware and maintenance!