The Basics
So I've been working with Xamarin a decent bit recently, and am looking for a solution to a current problem. I've been using the WoWonder script recently, and launched it on a site. i can confirm that the site is working well, without any hiccups. Although I've reworked some of the UI / UX, and basic functionality, I haven't delved extremely deep into it.
I'm currently using the Mobile Timeline applications to link into the network. I've had to debug a decent amount of problems so far with the NuGet packages, syntax errors, as well as authentication / decryption errors. I solved the first two, and solved the last by switching the SSL & TLS options in the Android Options area.
I would normally seek help from the author of said project, but given people in the comments haven't always gotten their answers, and instead got the runaround (Not to mention the broken english), I thought Stack would be the better option.
So far, I've asked around, and looked around, but haven't found anything. This is my last attempt before I start breaking everything down, line-by-line. I haven't found anyone else having a similar problem, other than the Xamarin > WP8 issue.
The Problem
Screenshots:
https://1drv.ms/u/s!Aub_kvZQCqk8ii7fW8ntcn4dxh-W
https://1drv.ms/u/s!Aub_kvZQCqk8ii9Ksd86tPIHLXMo
SideNote: The project does use 'Xamarin Components," and the syntax / order of things is a mess. It's nothing that breaks anything or issues too many warnings, it just parses a lot that it can't find, or isn't relevant / needed / is outdated.
Edit:
It's difficult to copy the context of the error in the emulator, since it doesn't seem to be showing up in visual studio. I'll transcribe it below.
Code Snippet:
System.Net.HttpRequestException: 500 (Internal Server Error) at System.Net.Http.HttpResponseMessage.EnsureSuccessStatusCode()[0x0002a] in <dcbf7ae3bce147228fa58d5bc31257ae>:0 at WowonderPhone.MainPage+<OnLoginClicked>d_2.MoveNext()[0x00252] in <1284583bda884ff38ca175979b310f47>:0
This has since been fixed. It was a problem on the server side, but had to do with the script, as the person previously mentioned. It wasn't a problem with Apache directives, or heightened security, just an inconsistency in the script syntax. Unfortunately, since another person solved this directly, I don't know the exact margin of error.
Related
With PS ISE still being indicated as being deprecated and VSC being pushed in its stead, is anything being done about the performance of Powershell scripts in VSC particularly when debugging, which has never been great but is now laughable ?
I have seen other similar question(s) to the above. Is there anywhere that developers can go to try and ask for the resolution of such issues to be given a higher priority ?
The only times I've experienced performance issues with VS Code were while having a laptop with tons of scanners and AVs installed (official company laptop).
They were scanning VS Code and all the changes non-stop and this caused performance issues. I contacted my security department in my company and requested to add VS Code files to the whitelist. That did it and problems never occurred again. I had the same issue with Windows Terminal btw.
BUT what you can do is create an issue in VSC's official GitHub repo: https://github.com/microsoft/vscode explaining your problem with VS Code. It'll be nice to include anything devs request, because maybe there is something in the code that is performance-heavy.
Based on your PS version (if it's > 6.0) you can post an issue here: https://github.com/PowerShell/PowerShell
I'm using Visual Studio 2019 and I'm debugging an angular spa app. The problem is that the 'Script Documents' section in the Solution Explorer that appears when you are debugging is really annoying.
I know why this is here and why it is sometimes useful, but 99% of the time I want to hide it.
The JavaScript debugging is working fine and I do not want to turn it off. I just want Script Documents to remain closed.
This problem is made worse when my angular app keeps rebuilding as I make changes. If I close Script Documents, it just re-opens when the app rebuilds. There has to be a way to hide it.
I've seen similar questions before but I haven't seen any clear answers.
So I have not yet figured out a way to do it. It was an issue in VS going back many versions and remains an issue today.
The work around I went with is the same one suggested in 2014 for VS2013, which is to right click on the project in VS that you are most interested in and click Scope to This.
This is a crappy solution but it works if you are having the problem, but you can't easily get back to the other projects in your solution.
https://stackoverflow.com/a/24116987/95041
As #Cory pointed out, there is a feature request. If this problem is affecting you, please upvote so it gets fixed.
https://developercommunity.visualstudio.com/idea/351537/provide-a-way-to-prevent-the-script-documents-fold.html
There is a question here about this already (though,short of re-installing Windows, which I'm obviously trying to avoid, the other solutions don't work for me), but I have some research to add, and a possible solution... which I don't understand, but perhaps someone here is able to shed light on how to implement it? I'm using Visual Studio 2015 Community on Windows 10 Pro x-64 with Anniversary Update (and latest cumulative update).
There is a possible work-around - details at https://social.technet.microsoft.com/Forums/windows/en-US/2f51398c-cef2-4686-9505-904d3f71ef6d/windows-10-applocker-packaged-app-white-list-blocks-store?forum=win10itprogeneral - where the resolution is to allow all Windows App Store apps, however no steps are given, so I don't know how to do that.
There is a relevant hot fix at https://support.microsoft.com/en-gb/kb/2719305, however that is targetting an older version of Windows, so I'm not sure of the repercussions of trying that. I'm leaving that as my last resort short of re-installing.
And finally, there is re-installing, as per the other thread on here, as the Anniversary Update is considered the suspect (and I'm past the rollback window). I already had the AU when I first tried UWP, so I never had it working to begin with to know if this is the culprit or not. I have never touched applocker myself (had never heard of it) - I have this problem out of the box.
Apart from the time involved, I don't want to re-install as there has been mixed success with it - for one person it fixed it, for another it fixed it initially but the problem came back. I am trying to get a permanent fix (and only re-install if I can't find one).
Anyone know a permanent fix for this? Or how to implement the first suggestion? Or implications of the second?
P.S. for the sake of completeness (and to pre-emptively answer this question), one of the things I already tried is the MS trouble-shooter for this issue (I think I found this one on MSDN from memory). It suggested using my MS login instead of my local user, and to change the temp environment variables back to default (I had them pointing to RAMdisk), but doing those things failed to fix the issue.
Well, I ended up re-installing Windows, having corrupted it along the way, and that ended up fixing the issue. I found along the way that the problem actually stops ALL apps from the store installing (I never did find out how to implement the store fix I mentioned in my question), and that provides a quick way to see if the problem is fixed (rather than trying to build/deploy your UWP app each time you think you've fixed it, just try installing a store app).
I did find something that MAY be a solution, at https://answers.microsoft.com/en-us/windows/forum/windows_8-winapps/this-app-wasnt-installed-error-0x80073cf9/92ec7c44-51ef-4c6a-9331-22958e01b4ec?page=1, which relates to how to recover from a corrupted user profile (I'm not being allowed to upload a snapshot of the relevant reply due to still being relatively new here. Sigh) - which I now believe to have been the cause - however I didn't get to try it out as I'd already corrupted Windows at that point. Note that none of the other solutions in that thread worked for me, so I would start with this one first, as the other solutions only worked for some people. If you have this problem then I would try that first before re-installing.
P.S. at one point it looked like the Anniversary Update may have caused the problem, however after I re-installed I tried before applying the AU, and then again with the AU, and it kept working afterwards,so that was NOT the culprit. It was the user profile/Windows being corrupt.
When I’m programming a Web app and I run into a problem that only seems to happen in one browser, I know that a somewhat-essential step among my overall programming tasks as a “good citizen” is to stop coding for a bit and take time to report the bug in the right place—so it can get fixed and other Web developers (including me) hopefully won’t run into the same problem later.
In such cases with Firefox, I understand enough to know when the cause of the programming problem I’m seeing is in the core “Gecko” browser-engine code in Firefox (rather than instead being, say, a bug in the Firefox user-interface code—the code for the so-called browser “chrome”).
Given that, is there a URL that will take me directly the form where I can quickly get to the right bugzilla “product” and “component” to report a Gecko browser-engine bug against?
Having already reported a few bugs in the Gecko code, I am somewhat annoyed at being forced to use the form at https://bugzilla.mozilla.org/enter_bug.cgi, which seems to assume I’m reporting a bug for the first time and I want guided step-by-step help. But this ain’t my first barbecue…
https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&format=default is the URL you want.
That’s because in the case of Firefox, the right bugzilla “product” to use for browser-engine (Gecko) bugs is actually Core (not the Firefox component—and there is no Gecko component).
That URL above takes you directly to an actual bug-reporting page—that is, as you’d want, it completely skips all the designed-for-first-time-bug-reporters step-by-step guided-help stuff.
You do need to then manually choose the right “component” from the Component list there, but if you already know the right component, you can make a bookmark that includes it; e.g., https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=DOM%3A%20Workers&format=default is a URL that will let you report problems with Firefox Web-Workers behavior.
Adding the &format=__default__ parameter/value is the important part needed to get bugzilla to skip all the designed-for-first-time-bug-reporters step-by-step guided-help stuff.
I've Googled around a bit on this issue and haven't been able to come up with anyone else having an issue to this one, so a) I apologize if this is a known issue; and b) I'm thinking this proves that I must be doing something horrifically wrong, yeah? :-)
My application has a very rich landing page which is the first page that is shown after a new launch. It has a panorama control, a large background image (but much smaller than the 2000x2000 limit) and recurring and ongoing animations. Prior to updating my tools to the January refresh, this page ran relatively smoothly. After updating and running the app in the emulator, the background of this page is white (despite the fact that the emulator is on the "dark" theme), performance is quite poor (both in terms of swiping through the panorama and in terms of my recurring animations). When I run the same project on my device, all is well (since, quite obviously, my device's OS is not on the updated image).
Clearly I must be doing something grievously wrong to merit such a cataclysm, but I'm not sure what it might be. I've tried disabling bitmap caching in the places where I'm using it, removing third party tools I'm using such as Peter Torr's awesome tilt effect and his memory usage counter, and several other hail-Mary-style moves, and the problem remains. I also looked through the provided resources and change log to see if perhaps something related has changed, but I didn't see anything.
I'll try to provide example code later if it would be of any use to any would-be saviors out there, but the app is pretty complex and large in terms of lines of code and file size, so it might be a bit tricky. i just thought I'd toss this out there and see if anyone might happen to see it and think of an obvious solution.
Thanks so much in advance for your time and help.
P.S.: I cross-posted this question on the official WP7 dev forums. Sorry if that's against the rules - I'm not a regular SP-poster, as you can tell. If it's a problem, let me know and I can delete the other post.
I was ultimately able to resolve this by creating a brand new project using the updated tools and copying my code, assets, and relevant project settings into it. The app now runs flawlessly on the emulator (or, at least, the flaws in it are my flaws and not the emulator's :-)).
I believe I originally created the project on an earlier version of the SDK, so maybe I had some kind of invalid or incorrect project settings. If I get a moment later, I'll compare the project files to see if I can identify a setting or difference that explains the disparity.
Thanks to all who looked (and to Matt, who even responded :-)). I'll report back if I have any more information that might be of help.
UPDATE: Updating for anyone who might be having this issue as well - my resolution above was a false positive. Creating a new solution and copying stuff in does indeed work, but only until you save and close the new solution. Upon reopening, the problem recurs. Grrrr. I'll post back if I come up with anything else.