Dave Kidder's Break-it-Down Blog

How to Run a LightSwitch App in Azure without HTTPS (V3 Apps Only)

2013-03-29T14:42:00Z

IMPORTANT: We recommend that you use HTTPS for applications deployed in production and that the approach outlined below only be used for testing purposes. I will work on getting something posted about SSL Certificates and LightSwitch apps, as I am not finding anything straight-forward with a quick search.

Currently when you go down the “Azure >> Cloud Service” path in the LightSwitch Publish Wizard, you will run into this tab on the “Security Settings” page:

Unlike the IIS or Azure Web Site paths, you don’t get to choose whether or not you want to use HTTPS, it’s required and you have to pick a certificate (I won’t go into why, as this was implemented before I started on the team so I wasn’t there for the discussions). One significant problem that this requirement leads to is that attempting to launch an out-of-browser app that is configured to use HTTPS will fail if you are using a self-signed certificate:

“An error occurred while checking for updates. Make sure you are running the latest version of the application by uninstalling it from Add/Remove Programs in the Control Panel, and then re-installing the application.

Details:

Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED)”

In VS Update 2 CTP 4, we have introduced a runtime setting that will allow you to run without HTTPS. No changes were made to the Publish Wizard at this time so it will still require that you specify a certificate, but if you follow the steps below HTTPS will not be used. Note that the changes are for “V3” projects only, so you will need to right-click on the LightSwitch project in Solution Explorer and choose “Upgrade Project” in order for this setting to work.

You will need to edit 3 files to make this happen. Start by switching to “File View” in Solution Explorer.

First open the web.config file located in the Server sub-project and update this setting:

<add key="Microsoft.LightSwitch.RequireEncryption" value="false" />

Next, open the ServiceDefinition.csdef file located under the root LightSwitch project and add this setting to the ConfigurationSettings node:

<ConfigurationSettings>
    <Setting name="Microsoft.LightSwitch.Trace.Enabled" />
    <Setting name="Microsoft.LightSwitch.Trace.LocalOnly" />
    <Setting name="Microsoft.LightSwitch.Trace.Level" />
    <Setting name="Microsoft.LightSwitch.Trace.Sensitive" />
    <Setting name="Microsoft.LightSwitch.Trace.Categories" />

<Setting name

="Microsoft.LightSwitch.RequireEncryption" />
</ConfigurationSettings>

Finally, open the ServiceConfiguration.cscfg file located under the root LightSwitch project and add this setting to the ConfigurationSettings node:

<ConfigurationSettings>
    <Setting name="Microsoft.LightSwitch.Trace.Enabled" value="false" />
    <Setting name="Microsoft.LightSwitch.Trace.LocalOnly" value="true" />
    <Setting name="Microsoft.LightSwitch.Trace.Level" value="Information" />
    <Setting name="Microsoft.LightSwitch.Trace.Sensitive" value="false" />
    <Setting name="Microsoft.LightSwitch.Trace.Categories" value="Microsoft.LightSwitch" />

</ConfigurationSettings>

Save all these files, then re-publish. To reiterate, you still need to specify a certificate although it won’t actually be used. Create a new self-signed certificate through the publish wizard if you haven’t done this already.

Once the app is done publishing, browse to the site and you will notice that you’re hitting an HTTP URL instead of HTTPS. You should now be able to install your out-of-browser app successfully.

If you navigate to your Cloud Service in the Azure Management Portal and click on the “Configure” tab, you will see this new setting (and all the ones that were previously defined in the csdef/cscfg files) are here and available to update via the portal:

In the future we hope to get around to adding support in the Publish Wizard to let you choose whether or not to use HTTPS in the Cloud Service path, but for now, this should get you around the out-of-browser issue.

Avoid LightSwitch URI Casing Issue Using the URL Rewrite Module

2013-01-26T22:45:10Z

Late last year, some customers on the LightSwitch forums started reporting an issue that certain situations would cause an error with the message:

“The context is already tracking a different entity with the same resource Uri.”

“An error occurred while processing this request.”

One of the ways that this could repro was if the user changed a value on the first page of records on an editable grid form, went to the next page (without saving first) then paged back to the previous page. When this happened, the record would appear with its old value and wouldn’t have the * next to it to indicate that the record was modified. If you hit Save at this point, you’d get an error that read “An error occurred while processing this request”. The problem wouldn’t repro all the time for all users (always fun times for a tester), but we eventually figured out that the problem would occur if the casing of the application name differed between what the user had entered in the browser and what the application had been named on the IIS Server.

For example, if I had deployed my LightSwitch app by setting the Site/Application field in the publish wizard like this:

…then the application would have the casing “SchoolBooks” on the web server and entities returned from the server would have this casing in their URI. If a client uses the URL http://myserver/SchoolBooks to launch the application, everything goes swimmingly and users won’t hit the errors mentioned above. If, however, the user entered http://myserver/schoolbooks (all lowercase) then the trouble starts.

The issue is not specific to LightSwitch and the underlying cause is a well-known issue in the WCF Data Services stack regarding case sensitivity. At the time we found the issue being reported on the LightSwitch forums, our guidance was to make sure the users entered the correctly cased URL when launching the application. This obviously is less than ideal as you have no control over what users will enter.

One way to assure that the client does supply the correct URL when the application is launched is to use the IIS URL Rewrite Module. This module can do all kinds of cool stuff, but for our purposes it can help us by redirecting requests that come in with the “wrong” casing to the one we want. It does this by using a system that allows the administrator to define a set of rules to detect incoming URLs and rewrite or redirect them, in certain situations.

First, install the module so you can use it in IIS (note that you need IIS 7.0 or higher). After installing, open IIS Manager, click on the website that you need to create the redirect rule for:

You should now see “URL Rewrite” in the “IIS” section of the features pane, double-click on it…

…then pick “Add Rule(s)” under the “Actions” pane on the far right:

On the “Add Rule(s)” dialog, pick “Blank rule” from the “Inbound rules” section and hit OK

Now we’ll fill out the info for the rule. First, name the rule (I’ll just name mine the name of my app) and enter the pattern as I have done below:

The Pattern field is where we put the regular expression that we want to match on. Note that since we created this rule at the “Default Web Site” level, the URL that we’re checking will be relative to that (i.e. we don’t have to worry about the web site name, only what comes after the initial slash). The pattern that I have entered above means that it will match when the URL begins with “schoolbooks” (case insensitive, since “Ignore case” is checked). The (.*) at the end will capture the remaining string in the URL (we’ll need that later when we specify our redirect URL).

We now need to enter a “Condition” to our rule. The condition needs to tell the rule to “fail” when the URL starts with exactly “SchoolBooks” (i.e. we don’t want to redirect if “SchoolBooks” was hit, either through the user typing the right URL or through our initial redirect").

In the “Conditions” section, hit the “Add…” button:

Enter the following in the “Add Condition” dialog and hit OK:

What this is saying is that the rule should only be enforced if {R:1} (the first capture group in our regular expression, which will be the “schoolbooks” part of the URL) does not exactly match “SchoolBooks” (case sensitive since “Ignore case” is unchecked").

So again, the rule will run if the URL is “http://myserver/schoolbooks”, but will not if it is “http://myserver/SchoolBooks”

Lastly, we need to specify what to do if the rule detects the wrongly cased URL.

In the “Action” section, change the “Action type” to “Redirect” and enter the following in the “Redirect URL” field:

So this means that we’ll redirect to the URL that is “SchoolBooks” + whatever came after the “schoolbooks” part of the initial URL.

If our URL was “http://myserver/schoolbooks/default.htm”

{R:1} = “schoolbooks”

{R:2} = “/default.htm”

…so our final redirect URL will be “http://myserver/SchoolBooks/default.htm”

Now just hit the “Apply” button in the “Actions” pane and you’re done.

Now I can see if the rule worked. If I fire up Fiddler and try to hit http://myserver/schoolbooks/

I get this in the Response:

And of course the next request has the right URL

And, if we created our “Condition” correctly, we don’t keep redirecting to this URL until the browser gives up (this happened to me a couple times when making these rules because I kept forgetting the colon in {R:1} and {R:2}, turns out those are important).

So that’s it, no more casing problem. Hope this works for you.

Notes:

The problem with casing ONLY applies to the application name. The website name will automatically get lower-cased by the browser. So if I type HTTP://MYSERVER/SCHOOLBOOKS in the address bar, the browser will automatically change that to http://myserver/SCHOOLBOOKS

If you deploy your application to a website that is dedicated to this app (i.e. isn’t running other web apps) you can omit the “Application” part of the “Site/Application” field of the publish wizard and just supply the Site part. The URL for your app will then be http://myserver (no app name, no problem).

LightSwitch apps deployed as an Azure Cloud Service or to an Azure Web Site are deployed in the manner described above, so they don’t have the problem.

If you don’t want to use the URL Rewrite Module and you are publishing to website with multiple applications, your best bet is probably to:

Enter a lowercase name for your Application as users would be more likely to type all lowercase when typing the URL
Send users a shortcut to open the app and advise them to always use that to launch.

Declaring LightSwitch Publish Wizard Bankruptcy

2012-12-06T02:05:45Z

Sometimes if you attempt to publish the same LightSwitch project to different targets (e.g. first publishing to IIS then publishing to Azure) you can get some weird errors in the publish wizard. If you have switched your publish targets or if you have manually updated/removed settings from your .lsproj or .lsproj.user file, you can do what I refer to as “declaring publish wizard bankruptcy” to start with a clean slate (i.e. the following will wipe out all previous state the publish wizard was keeping track of):

Close Visual Studio
Make a backup copy of your entire solution directory (I’d rather be safe than sorry)
Delete your .lsproj.user file
Open your .lsproj file in a text editor and remove any of the following settings you see in the first <PropertyGroup> section:

<AdministratorFullName>
<AdministratorUserName>                          
<AllowUntrustedCertificate>                      
<DeployDatabase>                                 
<AddAdministrator>                               
<BootstrapperComponentsUrl>
<DefaultInstallLocation>                         
<DeploySchema>                                   
<PublishNewDatabase>                             
<PublishUrl>                                     
<PublishSite>                                    
<RemotePublish>                                  
<UseLightSwitchWebDeploymentProvider>            
<AzureAllowUpgrade>                              
<AzureAppendTimestampToDeploymentLabel>          
<AzureDeploymentLabel>                           
<AzureWebSite>
<AzureWebSpace>
<AzureHostedService>
<AzureHostedServiceLabel>                        
<AzureStorageService>
<SslCertificateThumbprint>
<LightSwitchPublishVersion>                      
<PublishServiceOnly>                             
<AzureCredentials>
<RequireSecureConnection>                        
<AllowAllWindowsUsers>                           
<DefaultDatabaseName>

5. Save this file

6. Open your project in VS

7. Attempt to publish, re-specifying all your settings.

So if you ever can’t get publish to work (after it has already worked) try these steps to see if it helps. Otherwise, I will see you on the forums

http://social.msdn.microsoft.com/Forums/en-US/category/vslightswitch

AX Window Management Tips

2012-05-04T03:50:30Z

It’s pretty easy to get tons of AOT windows open during AX development and sometimes windows will open in weird states (like way way off to the right side of the workspace). There are a few keyboard shortcuts related to window management that are essential to figuring out what’s going on with your windows.

Switching between AOT windows

Most people are familiar with the ALT + TAB shortcut to switch between windows. This doesn’t do any good for AX development windows, though, since they are contained within a parent workspace window. A much lesser known shortcut to switching between these developer windows is CTRL + F6. This will cycle through your open development windows. If you hit it one too many times and miss the one you wanted, you can cycle in the opposite order by doing CTRL + SHIFT + F6.

Arranging your AOT windows when they get lost

Sometimes AOT windows will size very weirdly or be positioned way off to the right or bottom of the dev workspace. Other times a window will get positioned so that it’s title bar is above the area of the workspace so you can scroll to, so you won’t be able to move it. To get out of these situations, you can use Windows Menu >> Cascade to arrange all of your open AOT windows so you can see them all. Then you can resize the one you were looking for. The keyboard shortcut for doing this is ALT + W, C (that is, hit ALT + W to open the windows menu, then hit C to execute Cascade).

Un-maximizing a window

Other times you’ll have a maximized window that you don’t want maximized anymore (like if you need to open another AOT to drag+drop between). CTRL + R, the shortcut for Restore, is how you un-maximize your window so you can move it around.

Declaring window bankruptcy

Sometimes you just have an unmanageable number of windows open and should do what I call “declaring window bankruptcy” by doing Windows Menu >> Close All. The keyboard shortcut is ALT + W, A. This shortcut also works with application windows if you execute this from an AX 2012 Application Workspace.

Here’s where everything’s at in the Windows menu to recap.

Also notice the list of open windows that appear below the “Close All” item. This will show you up to 9 open windows that you can easily switch between by typing the number next to the window name (e.g ALT + W, 2)

That’s it for this post, hope these shortcuts come in handy.

ReferenceTable & Table References on EDT

2012-03-05T04:19:52Z

This post attempts to explain the behaviors of the ReferenceTable property and Table References node on Extended Data Types in Microsoft Dynamics AX 2012

Synopsis: Lookup & View Details behavior are controlled by Relations (either Table Relations or legacy EDT Relations) for controls bound to table fields. Controls that are not bound to table fields, but have their ExtendedDataType property set, have their Lookup & View Details behavior controlled by the EDT settings ReferenceTable & Table References.

I recently saw a bug come through regarding the Table References functionality on EDTs not working correctly. Since I had no idea what the expected behavior was of this node (especially in relation to the ReferenceTable property) I started playing around with it some and contacted some developers on the appropriate team to find out what the expected behavior of these items was supposed to be. Below is a summary of what I have found out.

Notes:

Whenever creating an EDT which will set the ReferenceTable property, the core type of the EDT must match the type of the PrimaryKey on the ReferenceTable (i.e. Int64 for tables that use SurrogateKeys).

I will be using the terms bound and unbound controls in the following manner:

Bound control = a form control that is bound to a table field by having its DataSource & DataField (or ReferenceField) properties set.
Unbound control = a form control that is not bound to a table field, but has its ExtendedDataType property set. The most common use of unbound controls is in Dialogs.

Here we go…

If you only set an EDT’s ReferenceTable property here’s what you’ll get out of it:

Unbound controls that use this EDT will get Lookup and View Details behavior as long as the table you are pointing to uses SurrogateKey as its PrimaryKey. So if you point to DirPartyTable, you’ll get these behaviors, but if you point to CustTable (which doesn’t use a SurrogateKey) you won’t (without one more step that we’ll get to in the next section).

Another behavior you will get by setting the ReferenceTable property is when you drag this EDT onto the Fields list of a Table, you will be prompted with this dialog:

If you hit Yes to this dialog, a new PrimaryKey based ForeignKey relation will be created automatically. Once you have this table relation, any controls that are bound to this table field will have Lookup and View Details up and running to the table that was specified in the ReferenceTable property. If you do not add this relation, bound controls will not get Lookup/View Details behavior (also, when you drag this table field onto a form design, you won’t get a ReferenceGroup, you’ll get an Int64Control).

If you also add a Table Reference here’s what you’ll get out of it:

Actually there are a couple of different scenarios…

If you set the RelatedField property to the PrimaryKey field of the ReferenceTable, you will get exactly the same behavior as if you had only set the ReferenceTable property, with the exception that unbound controls will get Lookup/View Details behavior regardless of the type of PrimaryKey they are using. This discrepancy is probably a bug (which I will look into).

Example EDT for previous paragraph

If you set the RelatedField property to a field other than the PrimaryKey, you will get Lookup/View Details behavior for unbound controls, but you will not be prompted to add a ForeignKey relation when you drag this EDT onto the Fields list of a Table. If you don’t have a Relation defined using this table field you will not get Lookup/View Details for controls bound to this field. Note that for the unbound controls, the value returned from the lookup will be whatever field you set RelatedField to.

Example EDT for previous paragraph

If you also add a Filter here’s what you’ll get out of it:

Once you have added a Table Reference, you can additionally add Filters. Adding a filter to a Table Reference will restrict the rows that are displayed in the lookup. Take a look at the CaseProcess EDT for an example of this:

A lookup that uses this EDT (either an unbound control or a control bound to a table field that uses this EDT and has an appropriate relation) will restrict the records to those that satisfy the conditions that IsActive=1, IsTemplate=1 AND HierarchyType=5. Filters on different table fields are AND’d together where as Filters on the same field are OR’d together.

That’s all I got.

Synopsis redux: Lookup & View Details behavior are controlled by Relations (either Table Relations or legacy EDT Relations) for controls bound to table fields. Controls that are not bound to table fields, but have their ExtendedDataType property set, have their Lookup & View Details behavior controlled by the EDT settings ReferenceTable & Table References.