Codito ergo sum: 2011

lördag 17 december 2011

BankID: 32-bit running on 64-bit Linux

Since Finansiell ID-Teknik BID AB (a swedish company that provides e-legitimation (BankID)) does not support 64-bit Linux they have decided that you are not even allowed to download their application anymore.. Which is stupid, since it works on 64-bit Linux. So from now on we'll have to fake running on 32 bit to even be allowed to download it..

Anyhow, to get your (previously downloaded) bankid up and running on your 64-bit Linux in Firefox you have to install nspluginwrapper and also ia32 for the required shared 32-bit libraries:

First install the bankid application (after unpacking it of course) by using their installscript


$ sudo ./install.x.y.z.sh i

Then install ia32 and nspluginwrapper to be able to wrap the 32-bit plugin so it can run on 64-bit


$ sudo apt-get install ia32

$ sudo apt-get install nspluginwrapper

$ sudo nspluginwrapper -i /usr/lib/firefox-addons/plugin/libplugins.so

Then you should be good to go. Try it, worked for me in 64-bit Ubuntu and 64-bit Linux Mint.

And btw, this should work on a number of 32-bit plugins, not only BankID.

For swedish 64-bit Opera users, here is a guide for you! : http://blogg.solstad.se/2012/09/en-64bitars-opera-for-shb.html

onsdag 31 augusti 2011

PowerShell: Some gotchas

Useful reading about some gotchas in PowerShell, especially for users coming from VBScript: www.rlmueller.net/PSGotchas.htm

This is a must-read for anyone with a bit of previous programming experience, so you wont do the same mistakes as I did when it comes to functions in Powershell: http://www.simple-talk.com/dotnet/.net-tools/down-the-rabbit-hole--a-study-in-powershell-pipelines,-functions,-and-parameters/

My conclusion is: For simplicity, do not call functions like this: myFunc(attr1, attr2, ...)
Instead, treat all functions as cmdlets: myFunc attr1 attr2 ...

tisdag 19 juli 2011

ASP.NET Life Cycle

Just a link to MSDN about the life cycle in asp.net, really useful reading: http://msdn.microsoft.com/en-us/library/ms227435.aspx

onsdag 6 juli 2011

ASP.NET (4): A few gotchas for dynamic controls

Do This!

To summarize: Always assign your own IDs to the controls you wish to handle postback data and events for. Make sure your IDs are valid (keep away from the colon) and make sure you re-add your controls before the LoadComplete-stage.

Discussion

First and foremost, when you are using dynamic controls, make sure you create and (re)add them at the proper stages.

When adding them for the first time you can do it in any stage that is before the Render-stage, such as in an Button_Click event or whatever.

You could of course override the Render-function and add controls before you call the baseclass Render-function. But then again, why would you ever want to do that?

When re-adding them, as you must do with dynamic controls if you want them to stay on the page for subsequent requests, you must do it before the LoadComplete-stage. Or else they wont be able to get their postback data and raise any events.

A suiting place to re-add them would be in the PreInit-stage or in the Init-stage. When dealing with master pages one must take extra care though, since the master page is added as a child control to the page to display, all controls on it, and any of your own controls that resides within a <asp:Content>-tag will not be available in the PreInit-stage, so then you will have to use the Init-stage, or some other stage later than that.

A list and description of all (well, most) stages can be found at MSDN
Concerning master pages and the order of stages (events), see MSDN for that too.

No fake IDs!

When you are not specifying your own IDs for controls, they will get one automatically assigned to them. These IDs are generated from the nearest NamingContainer and from the number of controls currently in it. This is only in the standard case though, there are configurable exceptions in ASP.NET 4.0.

This means that if you do not assign your own IDs to your controls, you might face some problems with events not firing and postback data not being used. If the controls are added in exactly the same order on every request, then you might be fine. But if some of the controls are added in a different order every time, or if another control is added or removed to the NamingContainer, your automagically generated IDs will not be consistent across requests.

A note on IDs

Make sure you are assigning valid IDs too, for example: You cannot have a colon (:) in your id, if you do, you will not be getting your postback data and no events for that control will ever fire.

onsdag 15 juni 2011

ASP.NET 4: Breaking changes

When migrating your ASP.NET application up to ASP.NET 4 you might get some unexpected error when you try to run your application. If you have made the migration in Visual Studio 2010, most of the problems will have already been corrected, but not all.

Read through this article on www.asp.net for a list of problems and solutions that you might (will) encounter: http://www.asp.net/learn/whitepapers/aspnet4/breaking-changes

måndag 13 juni 2011

VB.NET: Finding registered event handlers

I was wondering if there was any way in VB to see if there are any registered handlers to a specific event. I knew it could easily be done in C#, but did not know of an equivalent for VB. And after some googling, I found it. But of course, with some "quirks"..

It seems that you can only check for registered event handlers on custom events, and only by the obscure:


... 

Public Event MyEvent As Action(Of T) 

... 

If MyEventEvent Is Nothing Then 

...

So, it has to be a custom event, and you have to append 'Event' to the name of your event.. And Intellisense will not help you as it does not even allow you to type the name of your event if you have not started the line with RaiseEvent...

I can live with the fact that I have to append 'Event' to the name of my event, but why does it have to be a custom event? Why does it not work with other events such as Button.Click?

I suspect that this is because of that the field MyEventEvent might be private or protected though. So maybe you could do it via reflection. But come on.

fredag 10 juni 2011

PowerShell: Useful info about strings

Strings in PowerShell are instances of System.String (.NET). This enables us to use all functions and properties we are used to from C#/VB.NET:

PS> $mystring = "Hello bob" 

PS> $parts = $mystring.split(" ") 

PS> [System.String]::Format("{0} {1}", $parts[0], $parts[1]) 

Hello bob

There are also a few string-specific operators that can be used: -split, -join, -f (scroll down to 'Special operators')

PS> write-host $("Hello {0}" -f "bob")

Hello bob

Notice the use of $(...) here, it is a sub-expression that is required in this case to make sure that the expression is executed first and sent to write-host as a single argument. See about_Operators (scroll down to 'Special operators') for more information.

Furthermore, there are special cases such as -like, -contains and -match in comparison operators that makes our lives even easier.

Concatenating strings is done in the usual way, with the plus-sign. Using variables inside a string can be done when using double-qoutes. Escaping on the other hand is by using the backtick, not backslash as most of us are used to:

PS> $myname = "bob" 

PS> $mystring = "Hello " + "$myname `"The drooling monkey`"" 

Hello bob "The drooling monkey"

And last but not least

A few wise words about the cmdlet Select-String and a "general rule" of PowerShell:

If you're parsing a string in Windows PowerShell, you're doing something wrong

Don Jones Read the article from Don Jones here

PowerShell: Fetching the current user

To get the name of the user running the script, use: [Security.Principal.WindowsIdentity]::GetCurrent().Name

You could also use $Env:UserName and $Env:UserDomain, but these are not always what you might think at a first glance. They contain the name of the user in the active environment, which is not always the same as the user running the script.

Example (assume that the user running this line is 'foo'):

runas /user:bar /env "powershell myscript.ps1" This would run the script as 'bar' specified, but with $Env:UserName set to 'foo' because of the parameter /env