I'm developing on my localhost a new Blazor server-hosted app. I launch the template that it starts you out on... looks very nice. I change the text in the tag, refresh my browser... and no change. I refresh and refresh only to notice no change. Is something wrong?
Then I rebuild and rerun the app again and the change happened. Why do I have to restart the entire server for a small front-end change? I have to do this on every change I make? Even though the changes are for the front-end? If so, then the development experience for MVC apps is way better. I don't have to restart my server for changing the code for the front end.
I know dotnet watch exists, but it doesn't help. It still restarts the server for every change I make for the front-end. I have to wait like 10 seconds for just changing some CSS? Please tell me if I'm doing something wrong, or if this is by design.
Also, I tried the web-assembly version of Blazor. Same results.
I guess you are running the app with the debugger connected? this prevents the recompilation. You need to:
Press Ctrl-F5 to run the app without the debugger.
This should work on Windows using IIS, but on Mac "it's a bit more complex". According to a MSFT representative, they are planning on enabling this functionality for Mac users, but this info is already over a year old (from April 2020).
This issue still happens, and for me is a major downside. It doesn't make any sense to have to recompile entire project just because I changed some text on a page. If this is a design choice, it's doomed! Can't have a designer dependent on developers to recompile whenever a small change is required on simple html! Even if you change an element style you have to recompile!
Related
In Visual Studio (2015) using an Android Emulator, is there a way I can make a minor update to a xaml view, and have that refreshed in the debugging application without having to rebuild and re-deploy the project?
Currently a build/deploy for debugging takes about 2 minutes, and having to make some minor UI style tweak and do the whole thing again is driving me nuts.
I suppose I'm asking if there's some ASP.NET MVC-like functionality where I can update a frontend file (cshtml, js, etc) and just refresh the page without reloading the project.
Xamarin Live Player lets you make live edits to your app and have those changes reflected live on your device. Your code runs inside the Xamarin Live Player app – there is no need to set up emulators or to use cables to deploy the code!
https://www.xamarin.com/live
It does have limitations, be sure to read the Limitation section:
https://developer.xamarin.com/guides/cross-platform/live
I have a Mac desktop application developed using Xamarin.Mac and XCode. The application is loading views that should have a considerable amount of content as blank/white screens for a select few end users. While I've not been able to reproduce the issue locally and it doesn't appear to be impacting many people, it does happen consistently for a handful of users(6 out of over 4,000 at the moment). The app works just fine for the vast majority and uses a main window controller that sets the content view as needed by calling the applicable ViewController. When the views in question are loaded for the given users, it renders as a blank white area.
I did notice however that at least some of the objects in the views are actually there, just not visible. For instance, one view has buttons that are still "there" as you can click on them if you know where they are supposed to be positioned(and they also fire correctly) but they are not actually visible as the area is all white with no visible content. It's as if everything is loading properly but the UI just isn't cooperating in displaying objects that are actually there. The closest thing I could find was this Diagnosing run loop issue (partially frozen UI) in Cocoa application
However I'm not sure it's the same problem and there was no resolution for that either. Has anyone else ever encountered something like this?
Ok, got some new info. After doing a remote session with a user we had no luck with the hardware and the console didn't provide much insight, however we did stumble across a workaround that fixes the issue and may give some clues as to the real problem.
When the application is initially installed, we prompt the user to ask if they want it moved to the default Applications directory. They do not have to move it as it will work the same from pretty much anywhere but we do this for convenience. For the users having this problem, we noticed that they all had the app installed in the Applications folder. By sheer luck, one user accidentally chose to not move the app after reinstalling it per our support team. When the app was installed in his default Downloads directory, the problem vanished and the app worked as expected.
After testing various other directory locations(Downloads, Documents, etc.) we found that the issue only seemed to exist if the app was installed in the Applications directory. Furthermore, if the app was installed in the Applications directory, we could simply move it or copy/paste it to another directory outside Applications and when launching it from that new location the issue was resolved.
Seems like there is something specific to the default Applications directory that is causing this to happen(as odd as that sounds). Keep in mind that even when the app is installed in the Applications directory, this issue only happens to 7 people out of over 4,000.
Any ideas as to what might be special about that directory that could explain what we're seeing?
I have a console-based server and client application which talk to each other over a TCP socket on localhost (although eventually will be used on separate machines).
I see that if I manually launch the server target and then the client, XCode seems happy enough to run them both in separate debugger contexts, they connect and work just fine.
Ideally I'd like to set it up (via a scheme or pre-run step or something) such that I can one-click 'run' (or cmd-R) and both these contexts pop up and run happily.
So far my experiments with the post-run script (for the server) passing "$(BUILT_PRODUCTS_DIR)/cclient" to /bin/sh seems not to work, and this is less than ideal anyway because it wouldn't run in a debugger context anyway.
Is there a way i can easily set this up?
Thanks,
DaveM
EDIT: Added a screenshot of what I can achieve with several clicks, but would like to get to with one click/key-combo...
You can set up scripts and other actions in breakpoints.
Click on the left side of editor to create a breakpoint, and CMD+OPT+click on the breakpoint icon to edit its options.
Also, you can choose the 'Automatically continue after evaluation' option, for convenience.
For details, see Session 412 Debugging in Xcode from WWDC 2012 videos. This session just happened to demo debugging skills with Xcode in a client-server setting.
I'm writing a WP7 (Mango) application.
I store values in WP7 IsolatedStorageSettings.ApplicationSettings, then I call IsolatedStorageSettings.ApplicationSettings.Save();
If I press back, and leave the screen, and I come back I can read values just fine.
However if I press restart in the debugger (or just restart from the emulator) the ApplicationSettings throws a KeyNotFoundException, as if it didn't persist...
I haven't yet tried it on device, I don't have one available right now.
What can I possibly be doing wrong?
It turns out the problem wasn't in the emulator AT ALL, so everyone suggesting this is "by design" in emulator turned out to be wrong (but I can't undo my upvotes as they are locked).
The problem was that I tried to persisting a non-serializable class, and wp7 handled this by throwing away ALL my settings at next Save(). When I removed that single Add() (or more precisely serialzied that object with JSON.net (which COULD handle it), and persisted the json string) all my problems simply went away.
Still, ridiculous behavior on wp7's part.
This behavior is "by design" on emulator.
I suggest, below steps for your code.
1. Check Key is available or not
2. If not, then set default value to it.
Check that question: Automatic login process in Windows Phone 7.1 application
On emulator IsolatedStorage is not persistent after reload and that's for both files and application settings.
You can use Isolated Storage Explorer Tool from wp7 sdk to take a snapshot of isolated storage content and restore it after the restart: Click
That problem doesn't occur on real device where Isolated Storage is persistent.
I got the same error(The error occurs because after you stop the debugger the key get deleted), and I posted a question regards this: Automatic login process in Windows Phone 7.1 application. suggest you to use site settings instead of application settings. One more option:http://www.codeguru.com/csharp/.net/wp7/article.php/c19215/Using-Isolated-Storage-for-your-Windows-Phone-7-WP7-App.htm. Hope it solves your problem.
I'm using Mobile Safari's cache manifest file to store a multi-page data entry application that is run on an iPod Touch (version 3.1.3) in offline mode. The application writes to the client-side database by way of the persistence.js ORM. This all works fine.
However, I run into the occasional, extremely hard to reproduce problem whereby Safari just seems to forget that the pages are cached. When this happens, the "Cannot Open Page" alert appears, which is the same one that comes up when you attempt to visit a non-cached website with the wi-fi turned off. The only way that I've found to fix this is to reconnect to a wireless signal and visit the site while online, which seems to set the cache straight. This is easy to do when you're in the office, but not so easy to do out in the field.
I'm not trying to reference anything outside of the cached resources, and I've verified that the application is cached by running through the entire site while disconnected, sometimes successfully for days on end. I feel like there's a bug in the OS that messes with the validity of the cache. I'm not necessarily looking for a solution to the problem (but that would be nice), but rather just some confirmation that others have encountered this problem.
Using a cache manifest and lot of troubleshooting, I am able to reliably cache an entire application; Do note that this is a single page app with only a few separate file resources.
As a further enhancement, I have been trying to modify the DOM based on
window.applicationCache status
to inform the user about updates, ie:
tap here to apply update
If that were possible, I could swap the cache
window.applicationCache.swapCache();
Which would allow me to swap in the updated cache and then restart the page to provide a streamlined update mechanism.
Potentially even more streamlined than apps from the apple store.
I suspect that the applicationCache API was hamstrung by Apple to hinder web apps for this very reason. Having said that, I believe the level of support for "html5" APIs on mobile devices is among the most robust in apple's safari.
Following are a few problems I have noticed so far, in no particular order. Please note that this is not a comprehensive list of bugs.
I never get an 'updateready' event; this alert line never runs:
window.applicationCache.addEventListener('updateready', function(e) {
alert('updateready event status=' + window.applicationCache.status );
}, false);
I can not manually check for updates. The following code gives me an exception
try{
window.applicationCache.update();
}catch (err){
alert('exception:\n' + err);
}
It seems that as soon as I start to interact with the cache state at all, the caching stops working. The bugs are fiendishly elusive; pinning down & isolating any one issue can take a lot of time, especially since all this code runs flawlessly on other browsers (chrome).
Now here's a good one:
I suspect that if you pin an app to your home screen, iCloud "backs up" resources and restores them after you run the app for the first time from the home screen. To avoid this issue, you may sometimes have to rename files. I have proven that apple makes discrete backups of obsolete components by
removing them entirely from my app server
deleting the pinned web apps from home screen
clearing all the caches
opening the app url in safari
verify that its the newest version
pin to home
verify that the pinned app the newest version
close it
run again - and its back to the old one, no longer on your server.
Finally, if you run the pinned app while the phone is in airplane mode, iCloud will not be able to restore the obsolete files. This proves that it's coming from over the air.