HttpListener and SSL
This guides you how to do SSL mutual authentication with just an HttpListener. IIS is totally different of course.
This guides you how to do SSL mutual authentication with just an HttpListener. IIS is totally different of course.
HttpClient is a great class for exposing full power of http requests/responses and using Tasks. However, finding any guidance has been difficult. There are snippets buried in http://wcf.codeplex.com and stackoverflow.
Here are some nuggets I need to keep in mind when using this class:
This is how I made this work
My System: iMac 27-inch, Mid 2011 Mac OS X 10.7.4
About This Mac -> More Info -> Sytem Report
Note: Model Identifier: iMac12,2
Copy: Boot ROM Version: IM121.0047.B1F
Finder -> Applications -> Utilities -> Select Bootcamp -> Show Package Contents
Select Contents -> Get Info -> Unlock -> Change Sharing & Permissions to Read & Write for all 3 Names
Contents -> Select Info.plist -> Get Info -> Unlock -> Change Sharing & Permissions to Read & Write for all 3 Names
Info.plist -> Open in Xcode -> DARequiredROMVersions -> Create an item and add in the right logical order. In my example added IM121 after IM61
<string>IM41.0055.B08</string>
<string>IM42.0071.B03</string>
<string>IM51.0090.B03</string>
<string>IM52.0090.B03</string>
<string>IM61.0093.B01</string>
<string>IM121.0047.B1F</string>
<string>MP11.005C.B04</string>
<string>MB11.0061.B03</string>
<string>MBP11.0055.B08</string>
<string>MBP12.0061.B03</string>
<string>MM11.0055.B08</string>
Scroll to the USBBootSupportedModels -> Added my model in the right logical order, but notice I did not add IM122 I added IM120
<string>IM120</string>
<string>IM130</string>
<string>MM50</string>
<string>MP60</string>
<string>MB80</string>
<string>MBP90</string>
<string>MBA40</string>
File Save -> Open Bootcamp if all worked you should now see 3 options on the second screen.
Hope this helps!
https://discussions.apple.com/thread/3410900?start=75&tstart=0
Posted via email from Adam Hathcock’s Life in Software | Comment »
New release with a couple fixes.
Posted via email from Adam Hathcock’s Life in Software | Comment »
Someone is actually using it or looking at it.
Posted via email from Adam Hathcock’s Life in Software | Comment »
Previously I discussed a novel new way of implementing INotifyPropertyChanged based on code I saw during a Build session.
As of yesterday, February 29th, the Visual Studio 11 & .NET 4.5 Betas are out, and included in the .NET 4.5 Beta comes a handy new feature, the CallerMemberName attribute. It is one of three new Caller Information attributes that have been added in this .NET Framework release.
It is joined by the CallerFilePath and CallerLineNumber attributes. These attributes tell the compiler to include information about the caller as a parameter when compiling a method call (no runtime logic).
With this new functionality we can code things like logging & tracing routines and INotifyPropertyChanged implementations without having to use string literals, slow reflection code, complex expression tree logic, or code weaving.
Leveraging CallerMemberName, we can now rewrite our previous implementation as the following:
public event PropertyChangedEventHandler PropertyChanged; private void SetPropertyT>(ref T field, T value, [CallerMemberName] string name = "") { if (!EqualityComparerT>.Default.Equals(field, value)) { field = value; var handler = PropertyChanged; if (handler != null) { handler(this, new PropertyChangedEventArgs(name)); } } } private int unitsInStock; public int UnitsInStock { get { return unitsInStock; } set { SetProperty(ref unitsInStock, value); } }Fast, clean, maintainable, and no outside dependencies!
Last, but not least, for those of you who may prefer a more conventional INotifyPropertyChanged approach, the updated .NET 4.5 MSDN documentation page for INotifyPropertyChanged uses the CallerMemberName attribute in it’s implementation example. (-;
Good stuff. The reflection always bothered me.
Posted via email from Adam Hathcock’s Life in Software | Comment »
I’ve really gotten into Nancy much more so than anything ASP.NET MVC. Nancy itself so much simplier and doesn’t have crazy conventions all over the place nor does it require any configuration file editing (if you choose for it not to). Razor is the best thing to come out of ASP.NET and easily works with Nancy.
The intro documentation itself is pretty good. Along with a couple of other tutorials I’ve found, it’s been a breeze:
http://www.kristofclaes.be/blog/2011/04/03/building-a-photoblog-with-nancy-and-simple-data-part-1-setting-up-the-project/
http://jhovgaard.net/from-aspnet-mvc-to-nancy-part-1
More examples:
http://theothersideofcode.com/lightweight-development-in-dot-net-nancy
Just to remember, here’s a code sample that allows me to self-host Nancy as a plugin in another application. Redirecting the base file path and doing some Razor config in code is all I need:
public class Bootstrapper : DefaultNancyBootstrapper
{
protected override void ApplicationStartup(TinyIoCContainer container, IPipelines pipelines)
{
base.ApplicationStartup(container, pipelines);
StaticConfiguration.DisableCaches = true;
container.Register<IRazorConfiguration, RazorConfiguration>().AsSingleton();
container.Register<RazorViewEngine>();
container.Register<IRootPathProvider, RootPathProvider>().AsSingleton();
}
}
public class RootPathProvider : IRootPathProvider
{
private readonly string BASE_PATH;
public RootPathProvider()
{
var path = typeof(Bootstrapper).Assembly.Location;
BASE_PATH = path.Substring(0, path.Length - Path.GetFileName(path).Length);
}
public string GetRootPath()
{
return BASE_PATH;
}
}
public class RazorConfiguration : IRazorConfiguration
{
public bool AutoIncludeModelNamespace
{
get { return false; }
}
public IEnumerable<string> GetAssemblyNames()
{
yield return “System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089”;
yield return “ComicRackWebViewer”;
yield return “ComicRack.Engine”;
}
public IEnumerable<string> GetDefaultNamespaces()
{
yield return “ComicRackWebViewer”;
yield return “System.Linq”;
yield return “System.Collections.Generic”;
yield return “cYo.Projects.ComicRack.Engine”;
}
}
Posted via email from Adam Hathcock’s Life in Software | Comment »
API Updates:
http://sharpcompress.codeplex.com/releases/view/83131
Posted via email from Adam Hathcock’s Life in Software | Comment »
The Lync client for Apple’s OSX platform was released recently - much to a sigh of relief from most Apple users. While Communicator 2011 was ‘OK’ it was on OCS 2007 R2 experience, not Lync, and so felt like the poor cousin of your fellow Windows Lync users.
Anyways, I ran into a problem. On all of my Mac machines Lync just wouldn’t run - I’d fire it up, sign in, and bang, it would crash. Nothing in the crash logs indicated much. It’s been infuriating. My google skills on this issue were pretty weak - searching for Lync for OSX/Mac didn’t result with any useful posts as the client was so new.
So, with much gritting of teeth I set about trying to track it down. Built up a new OSX Machine in this order:
Lion 10.7.0 -> Worked
Lion 10.7.1 -> Worked
Lion 10.7.2 -> Borked
RIght, easy you think - it’s 10.7.2 right? Oh if only it were that simple. Essentially what I worked out was that if I logged in to a machine that had syncronised Keychains from another machine running 10.7.2 then bang, Lync wouldn’t run.
So, to be clear, this machine running 10.7.0 on new account - just fine. Log in to account with sync’ed Keychain from another machine running 10.7.2 and it didn’t work.
Got closer then….So, after much digging around in the Keychain, I noticed something a bit odd in certificates - namely an ‘Unknown’ certificate:
After checking a clean 10.7.0/10.7.1 account this was not there - it’s only there on 10.7.2 generated accounts. Guess what - delete it, and your Lync client will work just fine.
How infuriating is that?
Reblogging this.
Posted via email from Adam Hathcock’s Life in Software | Comment »