I need to make sure the server instance always runs the latest code.
Grunt-contrib-watch does reload the watched files, but the server process isn't restarted with the new code, thus old behaviour is still online, new code i.
This Grunt task blai/grunt-express does appear to contain this feature:
serverreload
Setting this option to true will tell express task to start a forever
running server in a child process, and if any of your server scripts
change, the server will be restarted (using a dynamically generated
watch task)
UPDATE: Tried the serverreload option in grunt-express - it doesn't appear to do what I understood, it does not change the running server's code
Any chance to achieve the same feature with gruntjs/grunt-contrib-connect and gruntjs/grunt-contrib-watch?
Example: starting my server from the watch 'tasks' option does run my newest code, but this doesn't appear to be a valid answer (server does not respond to HTTP requests anymore). See my grunt connect gist for more details.
Related
We are developing an (internal) web service based on asp.net 4.8, with a fairly extensive REACT SPA front end.
For debugging purposes during development, we run an IIS server on the local (development) machine, and we do something separate to run a proxy web server for debugging the .js front end SPA (not relevant to the question at hand).
When we start up a Debug session in Visual Studio (2019), VS starts with "Contacting web server to start debugging" and then locks for a time. It clearly does something to start the web server (w3wp.exe), and waits for some reply, before doing what it is told to do in the "Start Action" section of the Web tab on the project properties page.
This is problematic behaviour because it does not attach to w3wp.exe until after it finishes it's "contacting web server to start debugging" operation. This is a huge problem, as our w3wp.exe starts doing all kinds of things that we have no visibility into.
So, can anyone explain to me:
What does VS actually do to "contact the web server"?
Can this be controlled? If so, how?
Can I get the debugger to attach to w3wp.exe right away?
Why does w3wp.exe start up and load its collection of binaries, only unload them and reload them, sometime multiple times?
In short, what the actual heck is going on under the covers at startup?
This (Identity Server 3 Contacting the web server hangs when launching debug mode) question and answer seem irrelevant to my situation
I note the field Override application root URL in the Servers section of the Web tab of the project properties and had hoped this might have something to do with it, but I cannot see any relation.
Partial answers that I will either edit as I find more info, or modify if others correct me, or delete if someone answers completely. The answers to (1) and (2) above are this:
VS obtains the URL of the target web site (I will call this targetServer) from the Project URL entry in the Servers section, Web tab, of the Properties page for the web project. This actually comes from the <webProjectName>.csproj.user file in the project directory. Depending on the selection of the drop down specifying the server type to use, it comes from:
IIS server (<UseIIS>true): the <IISUrl> element
External Host (<UseCustomServer>true): the <CustomServerUrl>
IIS Express: unknown
WARNING: When opening a project with <UseIIS>true, Visual Studio has the very nasty habit of interfering in the setup of your IIS server: it insists on changing the "Physical Location" attribute of the IIS server (that is, the server or virtual app, however you have it set up) to point to the project directory of the web project. Using the "External Host" option avoids this - see https://stackoverflow.com/a/48753054/1082063. (All other discussions of this issue that I have seen incorrectly say this cannot be controlled.)
VS then issues a request to the url <targetServer>/debugAttach.aspx, and the request shows as neither a "GET" nor a "POST", but a "DEBUG", whatever that is. Not sure what VS expects back from this before doing the specified Start Action
Presumably after VS gets some reply from its DEBUG request, it will attach to the process that resulted from this request. Not sure how it knows which process to attach to - perhaps the debugAttach.aspx returns process information?
VS finally executes whatever Start Action is specified in the section of that name on the Web tab of the project Properties.
I strongly suspect that the answer to (3) above is that one cannot get VisualStudio to attach any earlier than it does because it must use the information returned from the debugAttach.aspx request to know which process to attach to. However, putting the line System.Diagnostics.Debugger.Launch(); at the start of Application_Start will allow you to attach the debugger earlier when necessary. (In practice, once you get Application_Start correct, you seldom need to debug it.) See this: https://weblog.west-wind.com/posts/2011/Dec/15/Debugging-ApplicationStart-and-Module-Initialization-with-IIS-and-Visual-Studio for a very good article on the subject.
(4) was a result of quirks in our Visual Studio setup. The initial "hack" used to get around the WARNING in answer (2) just above, was to have a web site with a dummy "virtual path" and have the IISUrl element in Visual Studio point to this virtual path. Then VS could change the Physical path of this virtual path, and we didn't really care, because our Start Action was to start a proxy server for debugging .js in any case. The issue was that this resulted in two calls to Application_start, running on two separate threads: one for the main server and one for the virtual server. Because one of these was happening before the attach happened, we never knew it was happening and it was never caught in a break point. When our application_start became long (timewise - this is not a web server for public consumption...), the two executions of application_start became a nightmare.
The issue you're seeing in IIS is that VS is not launching w3wp.exe, but rather Attaching to Process. In order for VS to attach though the EXE has to be running first, and the time between starting up and attaching (if not already running) ends up being too late to catch the ASP.NET app initialization logic in Application_Start and Module initialization.
As mentioned in my old post there are several ways you can get this to work:
Restarting the application when the debugger is already attached
(by making a change in web.config to trigger an AppDomain reload)
Adding an explicit Debugger.Break() call in Application_Start
Use IIS Express to debug startup code
I have a strange issue. I build my Meteor app and run it on android device using -
meteor run android-device --mobile-server=<my_aws_ip>:3000
When the app deploys immediately it connects to the server (and my javascripts etc works). After a few seconds, the page refreshs and none of the javascript callbacks work. Please help me debug this issue.
More information: If I change the client (and not the server), and deploy it, for the first few seconds, the changed client gets shown on the phone. After the first few seconds, the version which is present on the server is shown. So I think Cordova or Meteor is trying to fetch the client code from the server, which is breaking the app. Is there a way to prevent this behavior?
Even more data points -
My aws code does NOT have android and ios platforms installed. Because of this, I think the cordova plugins are not installed, causing a JS break somewhere.
Easiest fix I can think of is remove cordova autoupdate. This is being added by meteor-platform package. If I clone meteor-platform and comment out the cordova autoupdate, the app doesn't load.
Is there another way of removing autoupdate?
This sounds like you have a different version of your app deployed at the mobile-server address.
The local code is run in development mode. Your AWS one is likely in production mode (and may contain a syntax error).
When you run your app it sees the code is different and fetches the new/old (different) version with a hot code reload - hence the page refresh/flash.
To fix this, you need to find the syntax error in your code. It's best to view the ADB logger or run with meteor run --verbose android-device ....
This will provide a bit more information such as an Uncaught exception: cannot read .. of null error type error.
It's hard to say what the error is. The error prevents the rest of your code from executing. In production mode the entire project is one JS file. If there is an error of any kind half way along the file, the rest of the file will not execute.
Also, try loading <my_aws_ip>:3000 in your browser and watch for JS errors in the JS console.
You can also run it locally with --production to simulate a production build environment locally.
Enabling autoupdate but without a page refresh:
Reload._reload = function (options) {
console.log("Next load will load new version");
};
I often run a dispatcher server in sbt ~run.
unfiltered.netty.Http(port)
.handler(plan)
.run()
Http.shutdown()
When I start up my server, it says:
Embedded server running on port 8080. Press any key to stop.
However, only ENTER will stop the server. Unfortunately, ENTER also stops sbt. How can I set up unfiltered so that it actually stops on any key within sbt? I would like pressing a key to stop the server and cause sbt to re-compile and re-run the application.
You can do continuous hot reloading using sbt-revolver and JRebel. There's a free license of JRebel for Scala users.
Start sbt shell.
reStart starts a forked JVM that's exit trapped.
If you installed JRebel correctly, compiled classes from ~products would get loaded into the forked JVM.
See Hot Reloading.
I'm having trouble implementing the Delayed_Job_Active_Record gem in my Production Environment with Nginx. The user submits a 'Contact Us' form, the relevant controller action is called by Nginx and the following line of code fails:
#contact.delay.send_contact_form
Where the relevant method is:
def send_contact_form
ContactMailer.contact_us(self).deliver
end
Development Env: OK
On my local machine I have the pages served by Webrick. Everything runs fine, the delayed jobs go through the 'Delayed_Jobs' table and emails are sent.
Production Env - Rails Console: OK
On the server if I create #contact and call #contact.delay.send_contact_form manually, the delayed job goes through the delayed job table and email is sent.
Production Env - Webrick: OK
On the server if I start up a rails Webrick server I and enter the data for #contact via the web interface and then submit the job goes through the delayed job table and email is sent.
Production Env - Nginx: ERROR
The application is currently served by Nginx.
If I visit the interface via Nginx and enter the data for #contact and submit the page hangs.
The Production Log gives the following error on the controller action, (referencing the line above):
NoMethodError (undefined method `delay' for #< Contact:0x000000052962b0>)
I have also confirmed that the versions of Rails, Ruby and the Delayed_Job_Active_Record and Daemons gems are the same in both environments.
Any help would be greatly appreciated as i've been stuck on this one for a while. I want to find a solution that works with Nginx and which gives me the same functionality as 'Delayed Job'.
Thanks.
It turns out the problem was with Unicorn/Nginx not being restarted upon deployment of code updates, leaving them with incorrect configurations. The problem also occurred when adding Devise and other gems to the application.
The solution initially was to log into the VPS shell after a deployment, (via Capistrano) and run the following:
Restart Unicorn:
/etc/init.d/unicorn_esg stop
/etc/init.d/unicorn_esg start
Where *unicorn_esg* is the Unicorn reference to the application used in my deploy.rb configuration.
Restart Nginx:
sudo service nginx restart
The next step would be to incorporate this into the end of the deploy.rb script so it is automatically run at the end of each deployment.
I am running/debugging an asp.net mvc3 application from within Visual Studio 2010.
Anything static in nature is not called when I re-run the app from within Visual Studio.
(or even something simple like Application_Start())
Each time I want to run the webapp 'properly' I need to kill WebDev.WebServer40.EXE in the task manager before anything static is called again.
q1) Is this normal, and if Yes, why?
q2) If no, then I would expect the ASP.NET Development Server to be restarted each time I restart a debugging session. How can I turn this on?
UPDATE:
Recompiling sometimes causes Application_Start to be called, not always.
I've resorted to calling a batch file in the prebuild, eg
kill_WebServer40.bat
which contains
taskkill /F /IM WebDev.WebServer40.EXE
exit 0
If you embed those two commands directly into the pre-build textarea your compilation will fail if the WebServer isnt running already. This linked helped fix that.
Surprised this wasn't discussed more/previously - when developing an app, as if you have any static data/caches and you want to run the application 'clean' you would run into this issue.
Yes it's normal. It will restart if you touch the web.config or recompile. The development server continues to run the application in the background after you stop debugging.
You can stop the development server in the task tray by right clicking on the icon and choosing stop.
There isn't a way to force a application restart every time you hit debug. This would only be needed for the edge case where you are debugging application start up. Just hit rebuild before debugging and it will have the desired affect.