Prior to migrating from Mobile to App Services I could change node.js APIs in real time. Now changes seem to take an undetermined time to go live. I don't know if they're now being compiled or cached anywhere along the way. Ideally I would like to regain the ability to effect immediate change.
Technically, there is a file watcher that watches a subset of the files in your site - when you change one of those files, the site is meant to restart, thus making your change go live. This is configured in the web.config file which is a part of your site.
Make sure that the web.config is configured to watch the files you are interested in.
Restarting the site manually is a backup step that is effective.
Related
I'm finding the iterative development cycle quite slow on service fabric as opposed to a standalone .NET Core web application. It does not look like browser link works, hell even refreshing the page doesn't update HTML. From what I can see, you need to restart the whole fabric to update HTML changes.
There has to be something I'm missing.
We have this feature in the pipeline. Will be a few months out, but is coming.
To enable quick iterations on static files and other files that do not need build time compilation, the current hack is to start debugging your app or deploy it to the cluster so it's running. Find the files in the cluster node directory (Typically C:\SfDevCluster\Data\_App\_Node_0\....) edit them there and refresh your browser. Remember to copy changes over to your source before stopping debugging or removing the app, as this will delete those files.
Make sure to set you local cluster in one-node mode, to ensure you only have the files being served from one directory.
We're developing a solution which uses Ektron. As part of our solution we all have local IIS instances (localhost) and deploy to this local instance as part of the development life cycle.
The problem is that after a deployment and once dll's are replaced IIS restarts and the app pool is recycled, this means that Ektron dll's need to reload themselves.
This process takes an extended amount of time.
Is there anyway to improve the loading time of "Ektron"
To some extent, this is the nature of a large app running as a website rather than a web application. Removing the workarea from your local environment is one way to get this compile time down, though this will naturally not work depending on your workflow, for example if you are not using a separate dev DB or if you are storing the workarea in source control.
I have seen some attempts to pre-complile the workarea and keep the working code in a separate project (http://dev.ektron.com/forum.aspx?g=posts&t=10996) but this approach will only speed up your builds, not the recompilation of individual pages that will occur after a build as a result of running as a web site.
The last (and least best-practice) solution is to simply avoid making code changes that cause a recompile, like modifying app_code. Apps running as websites are perfectly happy to recompile a single page's codebehind without regenerating DLLs, which is advantageous for productivity but ultimately discourages good practices like reusing code in libraries. Keep in mind that this is terrible advice, but if you have a deadline and are staring at an ektron page loading every 30 minutes it can be useful to know.
Same problem here. I found this: http://brianpereras.blogspot.com/2013/06/ektron-85-86-workarea-is-slow-compared.html
That says that the help documentation was moved to be retrieved from an online source (documentation.ektron.com). We're running Ektron 9, and I just made this change and it seems much faster on first load (after iisreset).
The solution is to set documentation.ektron.com to 127.0.0.1 in your hosts file.
There is not, this is just how IIS works. Instead of running a local instance of Ektron it's a good idea just to point your web.config file to the database of your test database and copy the /workarea folder to your local PC. You can't edit ektron locally but you can change the data on your test server and it will show up locally.
Folks:
I'm creating an app using Node Webkit. The purpose of this app is to display images and pdfs. The app needs to download those files from a central repository, and cache them locally. When the app runs offline, the files should still be available, and displayed.
On the face of it, this sounds like appcache is the answer - and that indeed is where I was heading when this was a pure webapp in a browser. However, now I've discovered node-webkit, and here we are.
node-webkit's GitHub wiki states:
"However, application cache is designed for browser use, for apps using node-webkit, it's less useful than the other two method, read HTML5 Application Cache if you want to use it."
But doesn't say why.
I've also researched node.js filesystem - but that seems like a whole magnitude of complexity above what I need.
Can anyone point me in a sensible direction?
Thanks.
It has to do with the nature of App Cache itself.
You specify a manifest file that lists all the static assets required for your app to run offline. You don't have any programmatic access to the cache to add and remove files via JS.
So for a node-webkit app, it'd make more sense to fetch these files and store them in the Application Support folder (Or AppData, depending on the platform). That's where the node.js part is really useful, the file IO stuff.
The great thing about PHP is that if you have something like
clothes.com, clothes.com/men.php, clothes.com/women.php
Then if you only edit the men's page, only that particular "app" will be restarted.
But on rack/Sinatra I have to touch the restart.txt file to restart the ENTIRE website.
Is there a way around this problem, so that users browsing other parts of the site wont have any problems while another part of the site get edited?
(i'm using mod-passenger on Apache, not that it's important..)
This would be true in all cases anyway for editing (non-inline) views (not layouts).
Aside from that, if you're really worried about this then I'd suggest using versioned folders to hold the application code. When you do a deployment, change the proxy to point at the newer version. Those who had already made requests will remain on an instance of Apache and the application that is already running, as long as their request remains alive, and seemlessly (unless you've broken something with the code) move to the new code on the next request.
It's also a convenient way to rollback to the/a previous version quickly and easily.
Check out the sinatra reloader from sinatra contrib
I have Lazarus(quite a lot like Delphi) application which downloads few files from https://example.com/UpdateFolder. And i was wondering if anything can be done in order for APP to know that it is downloading files from right website? Because if I am right there is a way for hacker to trick APP into going to different website and downloading wrong files and I think it is done somehow by editing system32/driver/etc/hosts file. I would appreciate any suggestions
It depends entirely on your application that downloads the files. If it's able to handle SSL you have nothing to worry about AFAIK, since you need a trusted certificate before it'll make the connection, which will be hard to fake with a Windows host file edit.
Alternatively, and this is why we have domain names in the first place - so a last resort, you could hard-code the IP address of the server that contains the updates and do a trace to make sure the IP of the website your application is connecting to, is the same one you have on file.
However, this makes it very difficult if that IP changes, since you then need to roll out a new update of your entire application (or dll's responsible) just for that, and makes the process that much harder to maintain...