If you've read any materials on Model-View-ViewModel (MVVM), Windows Presentation Foundation (WPF) or Xamarin, chances are you've seen the work of Laurent Bugnion. Based in Zurich, Switzerland, he is a prolific writer and speaker in the software development world. He's the author of the well-known open source framework MVVM Light Toolkit for Windows Phone, Windows Store, WPF, Xamarin, and of the popular Pluralsight reference course about MVVM Light. He's also the senior director for IdentityMine, a Microsoft gold partner for technologies such as WPF, Xamarin, Pixelsense, Windows Store, Windows Phone, Xbox and, generally, UX.
In October 2010, he published the book, "Silverlight 4 Unleashed" (Sams Publishing). It was an advanced sequel to "Silverlight 2 Unleashed" (2008), which was published by the same company. He writes for MSDN Magazine and other publications, writes apps for Windows Phone, Windows Store, WPF, Xamarin (iOS and Android), and ASP.NET and his blog is on blog.galasoft.ch.
This is Bugnion's ninth year as a Microsoft Most Valuable Professional (Windows Application Development), his second year as a Microsoft Regional Director and his first year as a Xamarin Most Valuable Professional.
Lafe Low is the editorial liaison for the Enterprise Computing Group Events team.
Posted by Lafe Low on 05/05/20150 comments
Fiddler is a great help when diagnosing problems with Web sites, investigating performance concerns and modifying requests sent to Web servers. Because mobile devices are responsible for more traffic to Web sites, you should know how to use Fiddler for mobile clients, as well.
You can simply run Fiddler on your PC on its default port of 8888, configure it to "allow remote computers to connect" in Fiddler Options on the Connections tab, and ensure any firewall allows traffic on that port. Use ipconfig on the PC to determine its IP address. Then set the proxy server on the mobile device to point at the given IP address and port 8888.
In iOS, you'd set this on the Wi-Fi connection under the HTTP Proxy section by choosing Manual. Open the browser on the device and as you visit Web sites, you'll see all the traffic in Fiddler. Now use all the great features in Fiddler you’re used to for mobile clients.
Robert Boedigheimer works for Schwans Shared Services LLC providing business solutions with Web technologies and leads Robert Boedigheimer Consulting LLC. He’s been designing and developing Web sites for the past 18 years including the early days of ASP and ASP.NET.
Posted by Robert Boedigheimer on 05/01/20150 comments
Here are five of my favorite keyboard shortcuts in Visual Studio. There's a good chance at least one of them will be new to you.
Move Code Alt+Up/Down
This keyboard shortcut is new in Visual Studio 2013. If you put the cursor on a line of code and use the Alt+Up Arrow keys, the line of code you've selected moves up. If you use the Alt+Down Arrow keys, the line of code selected moves down.
Create Collapsible Region Ctrl+M+H/Ctrl+M+U
Chances are you've noticed the "+" and "-" symbols in the margins that let you collapse and expand your classes and functions. Did you know you can create your own collapsible regions? If you select a section of code and then use the key sequence Ctrl+M+H, you turn that region into a collapsible/expandable region. The key sequence Ctrl+M+U will remove the collapsible region. It doesn't delete the code, it just removes the icon that lets you expand and collapse.
Comment Code Block Ctrl+K+C/Ctrl+K+U
Whether it's because you're trying to track down a "but," or experimenting with code change, from time to time you'll want to comment and uncomment blocks of code. If you select a block of code and use the key sequence Ctrl+K+C, you'll comment out the section of code. Ctrl+K+U will uncomment the code.
Peek Definition Alt+F12
When you're going through your code and you want to examine the code in the method you're calling, many programmers will use the F12 key or the pop-up menu option Go To Definition. Go To Definition will navigate to the called method; however, many times you don't need to navigate to the code. Sometimes, you just want a quick look at the method. If you've installed Visual Studio 2013, there's a new keyboard shortcut -- Alt+F12 -- that will give you a preview of the method being called inline. You can use the Esc key to close the preview.
Navigate Forward/Backward Ctrl+–/Ctrl+Shift+–
When you have multiple files open at the same time, you might want a way to quickly move back and forth between two or three different locations in your code. If you've moved from one location to another you can use the keyboard sequence <Ctrl>+– to move to the previous location and then you can return using Ctrl+Shift+–.
Susan Ibach is a developer evangelist at Microsoft Canada. She loves to talk about Windows Phone, HTML5 and the cloud and has worked as a consultant doing programming, testing, data conversions, rollouts and also as a trainer teaching Oracle, SQL Server, SQL Server BI, and .NET programming. When she's not staring at an LCD screen, she's doing martial arts with her kids, out running or enjoying her husband's cooking.
Posted on 04/17/20150 comments
Visual Studio wants to keep you informed of important information, such as available Visual Studio updates, license expirations, or alerts. These notifications are now available directly from within Visual Studio. Just click on the flag icon in the Visual Studio 2013 title bar.
Prior versions of Visual Studio provided the notifications in a pop-up balloon that appeared in your Windows task bar. In Visual Studio 2012, the pop-up balloon appears and disappears so quickly, it's easy to miss. And it isn't obvious how to display it again.
In Visual Studio 2013, this process was improved by moving the notification into the Visual Studio title bar. That way you can review the notifications at any time. Hover over the icon for a quick overview of the notifications. Then you can click on the notification icon to display the notification window.
The notification window contains messages and alerts. Many notifications provide a link to an action. Hovering over the link will give you the notification details. Then you can click the link to perform the action. After you've viewed a notification, it's no longer considered new.
Deborah Kurata is cofounder of InStep Technologies Inc. and has more than 15 years experience in architecting, designing and developing successful applications. The author of several books, Kurata speaks at conferences such as Visual Studio Live!, DevDays and TechEd and has been recognized with the Microsoft MVP award.
Posted by Deborah Kurata on 04/16/20150 comments
Sometimes when you try to navigate to a site from a mobile device, you'll be redirected to the SharePoint mobile version of that site. The mobile view is a bit of a throwback to a bygone era. It gives you a restricted text view designed to work on older devices. Nowadays, mobile browsers are much better and you would much rather see the site rendered using responsive design.
Even worse—you might not have access to mobile pages, resulting in the authentication problems. Instead of fiddling with permissions, the best solution is to simply switch off the mobile view entirely. The easiest way to do this is to add a few lines to your web.config file. Add the following to the System.Web element following the SharePoint section that contains your SafeControls. It's normally about a third of the way down the web.config file. Here's the code to add:
<browserCaps>
<result type="System.Web.Mobile.MobileCapabilities,
System.Web.Mobile, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a"/>
<filter>isMobileDevice=false</filter>
</browserCaps>
Here's what that section of your config file should look like when you're finished:
<Action id="68c8f882-0c21-4190-9c85-ec9672bf8c16"
sourceFile="C:\Program Files\Common Files\Microsoft Shared\Web Server
Extensions\14\config\Webconfig.rs.xml" />
</MergedActions>
</SharePoint>
<system.web>
<browserCaps>
<result type="System.Web.Mobile.MobileCapabilities,
System.Web.Mobile, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a"/>
<filter>isMobileDevice=false</filter>
</browserCaps>
<securityPolicy>
<trustLevel name="WSS_Medium"
policyFile="C:\Program Files\Common Files\Microsoft Shared\Web Server
Extensions\14\config\wss_mediumtrust.config" />
<trustLevel name="WSS_Minimal"
policyFile="C:\Program Files\Common Files\Microsoft Shared\Web Server
Extensions\14\config\wss_minimaltrust.config" />
</securityPolicy>
<httpHandlers />
<customErrors mode="On" />
<httpRuntime maxRequestLength="51200" />
<authentication mode="Windows" />
<identity impersonate="true" />
If you want to do this programmatically, you can use the SPWebConfigurationModification class and deploy it as a feature by adding your code to the feature receiver.
Bill Ayers is a consultant developer and software architect who has been working on SharePoint since version 2003, and is a Microsoft Certified Master and MCSM, SharePoint. He specializes in Web content management and intranet portals. He has more than 20 years' experience in the software industry, and speaks regularly at international conferences and user groups. He's also a moderator on SharePoint.StackExchange.com and blogs at SPDoctor.net.
Posted by Bill Ayers on 04/16/20150 comments
Yes, it is possible to have your cake and eat it too. A good strategy is to use the latest CSS3 features in browsers that natively support them, but fallback to existing techniques like jQuery plug-ins or polyfills for older browsers.
Modernizr is a great free JavaScript library that detects what HTML5 and CSS3 features a user agent supports. Opacity controls how transparent an element is. CSS3 now has an "opacity" property you can set from 0 (fully transparent) to 1 (fully opaque). Modernizr supports conditional loading, so if it detects the user agent doesn't support the new opacity property, it can download the jQuery core library, which offers cross-browser support for opacity. This provides the best performance for current devices, while ensuring all users have the same experience with the site.
Robert Boedigheimer works for Schwans Shared Services LLC and leads Robert Boedigheimer Consulting LLC. He's been designing and developing Web sites for the past 18 years and is a columnist for aspalliance.com, a Pluralsight author, an ASP.NET MVP, and a third-degree black belt in Tae Kwon Do. He has spoken at industry conferences including Visual Studio Live! and TechEd, plus numerous national and international events.
Posted by Robert Boedigheimer on 04/16/20150 comments
When you use KnockoutJS for data binding, you'll generally want to be binding to observable properties exposed from your ViewModel objects. An observable is an object declared with knockout:
{ customerName = ko.observable("");}
When you go to set that property, remember to call it as a function object with a call like:
customerName("Homer"), as opposed to customerName = "Homer"
When you get the value, you likewise call it as a function:
var name = customerName()
This trips up even the most experienced Knockout programmers. As a result, you might want to check out either this post on Steven Sanderson's blog or this Durandal documentation page for ways to leave off the parentheses when working with observables.
Brian Noyes is the CTO of Solliance Inc. (solliance.net), a Microsoft regional director and MVP, and Pluralsight author.
Posted by Brian Noyes on 04/16/20150 comments
When writing asynchronous code using the Microsoft .NET Framework 4.5, it's tempting and easy to declare methods such as async void. Don't do this. You should only use async void on top-level event handlers. Instead, declare your methods as async Task. The async void methods wind up being fire-and-forget methods. That's the case even when awaited, because there's no task to actually await. Also, exceptions won't be properly propagated to your try/catch block.
Brian Peek is a senior program manager at Microsoft. Previously a Microsoft MVP in the C# discipline, Peek specializes in software development using a variety of Microsoft technologies and platforms and is also well-versed in hardware projects, graphics and game development.
Posted by Brian Peek on 04/15/20150 comments
Microsoft Azure Web sites provide a robust and easy-to-use container for hosting your Web applications. This doesn't just pertain to ASP.NET apps, but to several templates such as Drupal, WordPress, Orchard and so on. The service also provides first-class support for Node.js Web apps/APIs, PHP and Python. If you're new to Azure Web sites, you might think, "Big deal, this is just another Web host." You would be wrong. There's a ton of value you get with Azure Web sites that blows away your commodity Web hosters:
- The free version lets you host up to 10 sites in a multi-tenant environment and provides a great dashboard, FTP and continuous deployment capabilities including first-class support for Git (local repos) and GitHub.
- The shared version adds support for seamlessly scaling your app up to six instances/nodes along with enabling Web Jobs that provide worker processes for executing jobs on a schedule, continuously or on-demand.
- The standard version lets you dedicate not just instances, but full VMs to your application and supports auto-scaling your app based on metrics and triggers.
There's a lot more to Azure Web sites, whether you're a .NET, Node.js, PHP or Python developer. Learn more at the Azure Documentation page.
When you create your Azure Web site application, you get both an IP and URL. The URL takes the form of [your app].azurewebsites.net. Chances are you'll want your own domain name so that instead of [your app].azurewebsites.net, you can point to a specific address. You can do this in four simple steps.
Step 1: Ensure your site is configured for shared or standard mode. The free version doesn't support custom domains, which seems reasonable. If you started with a Web site in free mode, simply click on the Scale option and choose Shared or Standard mode and click OK.
Step 2: Copy the IP and Azure Web site URL. The next step is to make note of your URL and IP address. You'll need this for the third step in this process. Go to the list of Azure Web sites, select the site (but don't click on it) and click on the "Manage Domains" icon at the bottom of the command bar. This will bring up a dialog that includes your current domain record ([your app].azurewebsites.net) and your IP.
Step 3:Update the A Record and CNAMEs. Make a note of each and log in to your domain registrar's console. You want to look for DNS Management and either Advanced or Manage Zones or Manage DNS Zone File. You want to get to whichever console lets you configure your A Record and CNAMEs. These records allow for requests to your registered domain name to be forwarded to Azure specifically your Web site's host name. The result is your Web site will resolve to both [your app].azurewebsites.net and whatever domain you purchased.
The A record needs to point to the IP address you captured in step two. Replace whatever value is there with the IP address provided. When someone calls up your site, your registrar will authoritatively answer that request and pass it on directly to the IP address you provided. For the CNAME, there are three entries you need to make:
- Point www to [your app].azurewebsites.net -- This tells DNS that [your app].azurewebsites.net should be the destination (canonical host) for any DNS queries that begin with www (like your site).
- Point awwverify and awwverify.www to awwverify.[your app].azurewebsites.net -- This provides for a DNS validation mechanism so your Azure Web site can validate that your domain registrar has been configured to allow the Azure Web site to serve as a canonical domain in the event that a CNAME lookup fails. Be sure to save your file/settings.
Step 4: Enter your custom domain name in the Manage Domains dialog and check for validity. Pull up the Domain Settings for your Web site again. This time, enter your new domain name. If you want the Azure Web site to respond to both www.[yoursite].com and [yoursite].com, you'll want to create both entries. You'll likely see a red dot indicating that validation and/or CNAME lookup has failed.
This is simply the way the Azure Web site tells you records have not yet propagated. You can happily continue using your Azure Web site using the [your app].azurewebsites.net URL. When you come back to the dialog, the verification should succeed and any request for [yoursite].com should automatically resolve to your Azure Web site app.
Rick Garibay is a developer, architect, writer and speaker. He's passionate about distributed technologies and application lifecycle management and is currently a distinguished engineer at Neudesic.
Posted by Rick Garibay on 04/15/20150 comments
If you've ever created a Microsoft Azure Web site, you know how easy it is to get up and running. Given this simplicity, it's easy to get ahead of yourself and create your site without giving much thought to the datacenter where it will be hosted. For example, if the majority of your Web traffic will originate on the West coast, but you set up your site on the East coast, you'd benefit significantly by the reduced latency of moving to a datacenter closer to your users.
Another reason to change datacenters is if you're using a database or other linked resource residing in a datacenter different than that of your Web site. In this case, you'd pay for outbound bandwidth which otherwise would be free if all assets were hosted in the same datacenter. There's no easy way to make this change. It can also be problematic if you've set up a custom domain name for your site.
Fortunately, all is not lost. You can get to the same destination in just a few steps. First, create a new Web site, give it a unique name, and select the region to which you want to "move" your active site. Next, deploy your application to the new site using your preferred deployment method (such as Git, GitHub, WebDeploy, Dropbox and so on). Once you've deployed your app, test it using the URL assigned to your app.
Next, follow my simple four-step guide for assigning a custom domain to your new site. This time, replace the current A record (pointing to the IP address for your current site) in your registrar's DNS settings with the new IP address provided by Azure when you select Manage Domain for the new site. You'll also want to update the awverify, awverify.www and www key/value pairs with the new value for your assigned URL. For example, if your old site is named oldsite.azurewebsites.com, replace "oldsite" with your new site name. Follow the rest of the steps on my post for completing the set up on your new site.
As you're probably aware, DNS entries can take up to 48 hours to propagate, but often update much quicker than this. During this time, requests can bounce between your old and new site. To minimize downtime and disruption to your new site, set the TTL on your registrar's domain settings to the lowest value possible (GoDaddy is 10 minutes). After a few minutes, try stopping your old site and using your custom domain URL; see if traffic is directed to your new site. If you get a pretty looking Azure page, it means that traffic is still flowing to your old site (which is now stopped).
Restart the old site, give it some time and perform this test again. Within an hour or so, traffic should be going to your new site, as evidenced by your custom URL resolving despite your old site being stopped. If you have a highly critical production site and can't afford any downtime, you'll want to look at tools like Azure Traffic Manager to keep downtime to an absolute minimum. After it's resolved, remove your old site and enjoy your site running on your shiny new datacenter.
Rick Garibay is a developer, architect, writer and speaker. He's passionate about distributed technologies and Application Lifecycle Management.
Posted by Rick Garibay on 04/15/20150 comments