It's hard to believe but you can't do multiline comments in Powershell for some reason! Shame on you Microsoft! Here is a bit of a hack to allow you to right comments over multiple lines using a multiline string declaration:
@' This is a hack so you can do a multiline comment in powershell '@ > $null
Points to note...
Most web developers are aware of the IE alpha transparency problems with PNG images; or will be before long. A lot of developers use GIF images rather than the superior PNG format for this reason; which is a shame.
I was discussing the issue with Alex over at Prettier Pixels (a talented UK freelance website designer and builder) and he suggested this nifty IE PNG fix by TwinHelix that you can use to avoid the issues. Thanks Alex!
I long for the day when IE 6 support is no longer required!
I only managed 18 out of my 30 target for April and I've been too ashamed to post anything since :'(
Suppose I'd better get back on that horse and see if I can start getting some helpful blog posts back up on here!
Had an issue on one of my virtual servers which wouldn't process any ASP.Net documents (aspx, asmx etc), but would just return a 404. However, it would happily return other resources such as htm, txt, css. There was no web application logging, no logs in event viewer I had nothing to go on, until I remembered I hadn't checked my IIS logs.
The logs showed requests for the ASP.Net documents and that a 404 was being returned. This part wasn't helpful but the logs also provide a sub status code which was 2:
#Fields: date time s-sitename s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip sc-status sc-substatus
2008-02-27 12:39:13 W3SVC2 127.0.0.1 GET /default.aspx - 80 - 127.0.0.1 404 2
A quick Google led me to Microsofts IIS 6 pages explaining the sub status codes - bingo!
404.2 : "Web service extension lockdown policy prevents this request"
Knowing this and with the power of Google I resolved the issue in less than a minute. Just open the IIS6 interface, select the Web Service Extensions menu node, on the right you will see the web service extensions available - just select the ASP.Net extension and click the allow button.
Unless a user is on an internal network, there is no way server-side (I know of) to retrieve the mac address of a user accessing a web page, simply because it isn't sent in the http headers for a request. Any attempt to analyze the underlying network communications server side is pointless as it will just return the MAC address for the last routing machine. However, it is possible to retrieve the mac address of the user simply using client-side Javascript in IE.
<html>
<head>
</head>
<body>
MAC Address
</body>
</html>
Once you've accessed the WMI and got the MAC address you can even send the value server-side if necessary.
Implications: You are connecting to the WMI (Windows Management Instrumentation) for the local machine and therefore you may have a problem if your IE security settings are restrictive. Also, this won't work in non-IE browsers; only works for Windows operating systems. Not all that restrictive then?! ;)
Troubleshooting: If you get an 'automation server can't create object' error when running the script it is probably for one of the reasons below.
P.S. Another plausible option is to use an ActiveX control in connecting to WMI.
Login failed for user 'username'. The user is not associated with a trusted SQL Server connection.
This is a common error when setting up SQL Server instances from scratch and takes just 30 secs to fix.
Basically the SQL server instance you are conecting to has been configured to operate in Windows Authentication Mode and doesn't allow the use of SQL accounts. So change the Authentication Mode of the SQL server from Windows Authentication Mode to Mixed Mode (Windows Authentication and SQL Server Authentication). To do this right click your SQL Server instance in Enterprise Manager/Management Studio, select security and you should see the option in there. Hope you didn't waste as much time as I did on this :)
Email newsletters are common place for advertising products, services and events. Considering its uses, it is easy to understand why HTML newsletters are king; who wants to send plain text emails when we can send fancy text and graphics?! Unfortunately there are a lot of email clients out there wanting the HTML in a particular manner. Below are some simple tips to get you started with your HTML email newsletter creation.
1. Tables for layout not CSS... Unfortunately, there are alot of email clients that were developed in the last ice age still being used. This means CSS is poorly and wildly interpreted in terms of displaying your newsletter's layout. It's back to tables for cross email application consistency.
2. Inline styles... Although CSS shouldn't be used for layout, it is fine to use simple CSS styling for the content of the email newsletter. Some email clients can strip out HTML head styles, so put the <styles section in the body tag, or even better, put the css styles inline.
<p style="color: red;">
3. Javascript... Put simply, no JavaScript allowed! Most email clients will just strip it out.
4. Test, test and test... First test the design in Chrome, Firefox and IE, chances are if it works in these then you should have a consistent design across the web email clients and most app email clients. Finally test with as many email applications as possible (outlook, outlook express, thunderbird, lotus notes etc).
Using the above tips you should achieve a fairly consistent viewing experience of your newsletter for recipients. If you are having consistency issues the links below may help.
A Guide to CSS Support in Email A top compatabilities article
Example table layouts
Useful email marketing blog
CSS support in HTML emails of Hotmail, Yahoo! Mail and Gmail
CSS and Email, Kissing in a Tree
A big problem with ASP.Net MVC views is the amount of inline code you put in your views that could potentially result in errors that aren't apparent until runtime. Microsoft did spot this as a problem and kindly introduced a way of checking your views for compilation errors when you compile your source, here's how to enable the feature:
Open up your project file for editing either in Visual Studio by right clicking the project file and choosing 'Edit Project File' or just use your favourite text editor. At the top of the project file you'll see a PropertyGroup XML element with a child element of MvcBuildViews, change the value of this to true...
true
This results in a build event at the bottom of your project file getting called...
That's it! You now are that little bit more confident in your deploys :)
This will add an overhead to your builds, so depending on the size of your MVC project this could extend your build time substantially. However, thanks to a discussion with some other team members at Esendex (Alex and Jon) there is a way of avoiding the overhead the majority of the time. Create a new project configuration in Visual Studio, called something like Debug with Views Compilation. This will add a new PropertyGroup section in your project file for this configuration. Set the MvcBuildViews element to true in this new section. Remember to ensure the default section value for MvcBuildViews is false but set the release section value to true.
false true true
Quite useful if you are working within your MVC app and not changing the views at all.
If you are building a standard MVC project on a developer machine then everything should work fine. If your MVC project isn't standard you may find you have to play with the PhysicalPath part of the AspNetCompiler. To get our CI build machine building this project I had to change the PhysicalPath value to $(WebProjectOutputDir), this value is passed in as a parameter when calling the build on your project.
MSBuild.exe myproject.web.csproj /target:Rebuild,ResolveReferences,_CopyWebApplication /p:Configuration=Release; Architecture=x86;WebProjectOutputDir=build\release\web\;OutDir=build\release\web\bin\
Hope this info is useful to someone out there!
Given my new dev machine runs Windows XP x64 (64 bit OS), I've been considering the implications of compiling the assemblies and executables for different target CPUs.
First of all, no matter what target CPU you select, the .Net compiler STILL compiles the source to the Common Intermidate Language (CIL). The executable or assembly being compiled is only affected by this setting to set the platform status information on the assembly’s Common Language Runtime (CLR) header. The CIL is only turned into native code by the CLR at runtime using the Just-in-time (JIT) compiler.
Now here's the important bits, so pay attention...
Rule of thumb is... by limiting the CPU target at compilation you would be saying there is something being used by the assembly (something likely unmanaged) that requires 32 bits or 64 bits.