Wednesday 30 August 2017

VB.Net webforms website requiring OWIN Middleware

I've recently been attempting to write a new API system from scratch using .Net Core in C# - just to progress my knowledge and skill set. At the moment, this bit isn't complete yet but I've been thinking ahead as to how current production systems would use it securely when I finally do complete it.

We have lots of VB.Net websites that we haven't had time to convert into anything else due to time constraints and they mainly use Forms Authentication.

At some point, I want to change the sites so that they use a different type of authentication - by linking to the API for an OAuth token. To get these sites to do this, I need to change them so that they use OWIN middleware which can then connect to the API. I won't go into more detail here as there are lots of explanations/examples around regarding this aspect.

The aspect I have struggled with is in terms of using OWIN middleware with the particular set-up we have.

Lots of searching around does return lots of examples. However, I must be looking for something that nobody else does because for the sample site I am going to use; it's VB (not C#); it's a web site (not a web application); it doesn't use ASP.Net Identity (it's a custom system); it doesn't use Entity Framework and it isn't MVC.

Take all those examples out of the Google Search results and, well without maybe going past the first 2 pages, there's nothing!

I created an example Visual Studio web application in VB.Net using individual user accounts for security and that worked which was the closest system. However, this is a web application, and so copying the important files from the sample to my site didn't actually work.

After lots of wasted hours, the solution is rather simple as I just had the location of the startup files wrong!

Instead of using App_Start and the root directory for the startup files as per the example applications - just put both files (Startup.vb and Startup.Auth.vb) in the App_Code folder.

Tuesday 5 July 2016

Create a PDF mail attachment from HTML using .Net

The following is how I managed to get a PDF document created from a string of HTML using Select PDF and then converted to a MemoryStream for attachment to an e-mail.

First, create the HTML string. I use a string builder variable

Dim sbHTML As New StringBuilder

Then create the PDF document from the string (Imports SelectPdf is required)

Dim converter As New HtmlToPdf()
converter.Options.PdfPageSize = PdfPageSize.A4
converter.Options.PdfPageOrientation = PdfPageOrientation.Portrait

Dim docPDF As PdfDocument = converter.ConvertHtmlString(sbHTML.ToString, Nothing)

Then save the PDF to a memory stream

Dim bytPDF As Byte() = Nothing
Dim msPDF As New MemoryStream()
docPDF.Save(msPDF)
bytPDF = msPDF.ToArray()

Set stream to beginning so it can be read as an attachment

msPDF.Seek(0, SeekOrigin.Begin)

Finally, create the message

Dim mm As New MailMessage

and create the content type for the attachment (and attach it to the e-mail)

Dim ct As New ContentType
ct.MediaType = MediaTypeNames.Application.Pdf
ct.Name = "invoice.pdf"
Dim attach As New Attachment(msPDF, ct)
mm.Attachments.Add(attach)

Dispose and close objects after sending

msPDF.Close()
msPDF.Dispose()
docPDF.Close()

Friday 27 July 2012

Windows 7 64 bit "Network BIOS command limit has been reached"

I seem to always have this problem with a new machine. I don't know why Microsoft see fit to have it fail as default. I can only presume there is some security risk with it.

However as a developer linking to UNC paths, it's frustrating. Previous solutions didn't seem to work with a 64bit Windows 7 PC but this is how to solve it;

Add a REG_DWORD registry entry FCNMode and set its value to 2 to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\ASP.NET.

Wednesday 30 March 2011

ASP.Net Ajax: Calendar Extender lost Saturdays!

I think updating to a newer version of the Ajax Control Toolkit caused this problem.

I had a client call to say there were days missing from the calendar. When I looked it turns out it was just Saturdays. Through trial and error I established the problem was css related. I'm guessing that the calendar was picking up padding or margins from a table it was placed within.

The trick is to reset the calendar's own css code to the following (in the stylesheet):

.ajax__calendar_days table tr td, .ajax__calendar_months table tr td, .ajax__calendar_years table tr td {padding:0; margin:0;}

Tuesday 22 March 2011

ASP.Net: Default LinkButtons in non IE browsers

ASP.Net pages are only allowed one 'form' tag and that means multiple submissions within the page need to be handled to cover users who press 'Enter' rather than click the relevant buttons.

This is usually done by specifying the default button for a form or placing panels around content with default buttons within them.

As I've found out today though, this works perfectly for normal Button controls but not for LinkButton controls. Well, it works as expected in Internet Explorer but that's not good enough these days with Chrome and Firefox being just as popular.

Therefore, I had to do some digging and this is the code I found to cure the problem;

<script type="text/javascript">
var __defaultFired = false;

function WebForm_FireDefaultButton(event, target) {
    var element = event.target || event.srcElement;

    if (!__defaultFired && event.keyCode == 13 && !(element && (element.tagName.toLowerCase() == "textarea"))) {
        var defaultButton;

        if (__nonMSDOMBrowser)
            defaultButton = document.getElementById(target);
        else
            defaultButton = document.all[target];
        if (defaultButton) {
            if(typeof(defaultButton.click) != "undefined")
                defaultButton.click();
            else
                eval(unescape(defaultButton.href.replace("javascript:""")));
            event.cancelBubble = true;
            if (event.stopPropagation) event.stopPropagation();
            return false;
        }
    }
    return true;
}
<script>

It needs to be placed at the bottom of the page, before the 'close form' tag so that it overrides the javascript provided by the .Net Framework.