1. I downloaded breeze-runtime-plus-0.55 (the ToDo app) and compiled on my local machine with VS2012 RTM. It worked out of the box running in IISExpress.
2. I then changed the Connnection String in Web.Config to point to a real SqlServer 2005 located on our network. It worked.
3. I then Published the app to a Windows 2012 running in a VM on the network as an application running on port 80.
*Publish Method: WebDeploy
*Service URL: 192.168.168.176 (the ip address of the VM) for some reason DNS did not work with the VM name.
*Site/application: Default Web Site/ToDo
*UserName: mydomain\nstein
*I used my password - I am a domain admin so I did not think there would be a problem with security.
The connection validated.
On the next dialog, I used the connection string from Web.Config.
On the last dialog, the Preview looked ok, so I published.
4. I then went to an IE9 and hit the application. The screen was gray with no ToDo list. An F12 -> Network capture and refresh showed that I was getting a 404 with main.js. So I went to the Server and checked to make sure that main.js was there and it was. The 404 was looking for main.js in
http://192.168.168.176/Scripts/main.js when the app was pointing to
http://192.168.168.176/ToDo/whatever.
5. I got the Sales Rep Derick on the line and he pulled in a Developer who explained that Breeze expects the app to be from the base. He helped me delete the old app and reinstall as a new Website on port 8080. Now when I hit 192.168.168.176:8080, the app comes up. I do not like it. I would prefer that I could run from within the Default Web Site. But at least I know the problem exists.
6. So I went back to VS and added a ~/ to the front of the script tag to see if that would work.
<script data-main="Scripts/main" src="@Url.Content("~/Scripts/lib/require.js")"></script>
to
<script data-main="~/Scripts/main" src="@Url.Content("~/Scripts/lib/require.js")"></script>
It was a breaking change. Now when I run from F5, the app breaks at the third line of dataservice.js core = breeze.core,
It continues to break there even if I remove the ~/. They went off to see if they could repeat the problem and they were able to do so. I am sure a fix will be in the next build.
Nick Stein
9/24/2012