I have just converted a LightSwitch application to V2 and published it to Azure.
When I try to login, I enter my username and password and get this error:
Load operation failed for query 'Login'. An error occurred when parsing the Cookie header for Uri 'http://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.cloudapp.net/Web/Microsoft-LightSwitch-Security-ServerGenerated-Implementation-AuthenticationService.svc/binary/Login'.
After I got it the first time, I published the app again and reinstalled it and I still get the error.
Any ideas would be greatly appreciated.
Mark2012년 5월 6일 일요일 오전 4:41
I also have been experiencing this mysterious error for quite a while.
Exactly the same error message at login. Entering wrong login info generates proper validation message, so login system is operating. But correct login information will generate this error.
I tried everything I could have done searching for the answers everywhere. Not too many people seem to experience this error though.
Here is the background of my application.
1. When the app runs in browser mode, login works fine. When I deploy it as a desktop app and try to login, this error happens.
2. The app was developed initially with LightSwitch v.1 with no issue. Since converted to v.2 beta(VS11 beta) it is causing the error. But I am not certain whether this is directly related to version conversion.
3. When I create a new LS application and deploy it as a desktop app to the same server, no problem.
4. This error can be repeated deploying it to other servers as well.
5. Since the app is so large (70+ tables), it will be extremely difficult to rebuild the solution file from scratch. But that is the only option I can think of now.
6. The app requires desktop deployment to integrate with Office.
7. Windows 2008 R2, IIS, Sql Server 2008 R2
LightSwitch is the ultimate development tool for building business applications. Nothing compares at all.
But having such a difficult problem with nowhere to find help is a great pain at the moment.
Any suggestion could be greatly appreciated.
2012년 5월 7일 월요일 오후 12:24
- 편집됨 reachpoint 2012년 5월 7일 월요일 오후 12:37
This is almost exactly the same as situation as mine:
I upgraded my LightSwitch project and it is a desktop app. One difference is that I am hosted on Azure and you are not, and we are both getting the same error.
I am absolutely stuck here and can't proceed without getting this fixed.
Does anyone out there have any ideas about what might be causing this?
2012년 5월 8일 화요일 오후 8:51
- 편집됨 marks100 2012년 5월 8일 화요일 오후 8:52
Can you follow the steps outlined here:
Using Fiddler to get some traces might help in diagnosing what the problem is.
http://blogs.msdn.com/b/eric_erhardt/2012년 5월 9일 수요일 오후 9:31중재자
Just to confirm, I've had the same problem.
But I had to uninstall VS 2012/reinstall VS 2010, I just didn't have the luxury of trying to "solve" the problem. The client was really on my back about *me* breaking their app.
I wish that I'd found Eric's suggestion before I uninstalled/reinstalled, but I was obviously searching in the wrong place.
Yann - LightSwitch Central - Click here for FREE Themes, Controls, Types and Commands If you find a reply helpful, please click "Vote as Helpful", if a reply answers your question, please click "Mark as Answer" By doing this you'll help people find answers faster.2012년 6월 6일 수요일 오전 12:30
I have enabled all of these options and republished several times. I keep getting this same error with no trace information available. This is probably due to the fact that LightSwitch is trying to turn an assembly relative uri path into an absolute http uri: http://mydomain.com/Microsoft.LightSwitch.Client;component/screens/screenpresentation/internalframework/resources/resources/x.png
All I get from that in fiddler is a 404. The Login query actuall returns successfully with the proper permissions etc. If I publish the same app to the same IIS entry as a web application it works fine. However, I need the application to run as a Desktop application due to customer requirements.
As far I as can tell this is a bug somewhere in the OOB portion of LightSwitch 2012. Some information from MS regarding this issue would be much appreciated as there appears to be NOTHING we as developers can do to resolve this issue. There is not even a way to determine what is actually failing. All of the diagnostic options recommended in Eric's blog return no useful information and the only error detected via Fiddler or Trace.axd is the 404 error when LightSwitch attempts to load an embedded png file from a non-existent url.2012년 6월 24일 일요일 오후 4:47
Have you published as a desktop app? Or are you turning a web app into an OOB app (which is what it looks like from your reply above)?
Yann - LightSwitch Central - Click here for FREE Themes, Controls, Types and Commands If you find a reply helpful, please click "Vote as Helpful", if a reply answers your question, please click "Mark as Answer" By doing this you'll help people find answers faster.2012년 6월 25일 월요일 오전 12:00
Does anyone have an app publically available that reproduces this problem? I could try to debug it on the client end to see if I can learn anything that way. Send me the app's URL through my blog's "Email Blog Author" link. http://blogs.msdn.com/b/eric_erhardt/
I've never seen this error before, but it seems that this is a common issue we need to investigate.
http://blogs.msdn.com/b/eric_erhardt/2012년 6월 25일 월요일 오후 6:10중재자
From what I've gathered from the various posts that I've seen Eric, it seems to be a combination of some previous version of LS, prior to installing the RC, plus an upgraded project.
I don't have a project like that any more, sorry.
Yann - LightSwitch Central - Click here for FREE Themes, Controls, Types and Commands If you find a reply helpful, please click "Vote as Helpful", if a reply answers your question, please click "Mark as Answer" By doing this you'll help people find answers faster.2012년 6월 25일 월요일 오후 11:33
I have a project that can reproduce the problem. However, this is a project that I am actively building for a client so I cannot leave the broken copy up for too long. Any idea on how long you may need it to be online? If it is more than a couple days I may be able to post it to a separate URL or something. Let me know what you think and we can work something out.
Thank you for your help with this!2012년 6월 26일 화요일 오전 12:13
A day at the most is all I'd need it. Posting it on a separate URL is probably the best idea though. I don't want you to mess up any working copy you have now.
Email me a link through my blog, and I'll get looking at it.
http://blogs.msdn.com/b/eric_erhardt/2012년 6월 26일 화요일 오후 1:39중재자
So thanks to Eric I believe we have found the solution!
Looking at the authentication request via Fiddler Eric noticed that the application name contained spaces and suggested the issue was due to the name attribute in the forms element in the web.config
<authentication mode="Forms"> <forms name="Application Name" /> </authentication>
I updated all the references in web.config to substitute Application Name with Application_Name to remove the spaces. This included several of the provider configuration elements.
So hear is the catch. When you change the application name all of your user & role information is no longer associated with the application. This means that you must tell the publishing wizard to create a new administrator account in order to login. You should be able to recover your user & role information using a SQL script to update the provider records to use the new application name that does not contain spaces.
In my case I didn't bother because I only had one other user account and I will just delete the old records using a SQL script.
A HUGE thanks to Eric for his time, effort and expertise on this one certainly had me stumped! I hope this solution helps everyone else dealing with this issue.
2012년 6월 28일 목요일 오전 3:30