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.
Related
This title would be too long, but this is more isolated issue:
Why ASP.NET Core web application does not serve static web assets when started from command line and the ASPNETCORE_ENVIRONMENT is not set, or set to any other value than "Development"?
Context
I've created a new ASP.NET Core Web Application using the VS 2022 built in template (.NET 6, but I do not think the issue/question is .NET 5 specific) I did not altered the created application in any way
I am able to run my ASP.NET Core web application under IIS Express, or without IIS Express using Visual Studio, based on launchsettings.json., I mean using the green triangle dropdown, and pick WebApplication instead IIS Express
Just for the sake of curiosity, I've tried to launch the WebApplication1.exe from the bin folder. It starts, I can access it via browser using https://localhost:5001/, the page loads, but without CSS, JS. I can see that all requests for static resources have a 404 response.
I suspect that I should somehow configure the app, where the static web resources are. I see that the corresponding WebApplication1.runtimeconfig.json and WebApplication1.staticwebassets.runtime.json (formerly WebApplication1.staticwebassets.xml) are there... but later I figured out that magically the environment ASPNETCORE_ENVIRONMENT is related to the issue.
What I've tried so far?
In the command shell I set the environment variable to
SET ASPNETCORE_ENVIRONMENT=Development
...then started then I started WebApplication.exe, this case all is working, static web assets are served.
Question
In the very simple Program.cs and startup code I do not see any conditional logic regarding ASPNETCORE_ENVIRONMENT variable, so I do not understand the issue, why is the difference? (I've also checked the differences between the two appsettings.json and appsettings.Development.json: no related differences.
As an ultimate goal, I would like to automate the start of the WebApplication.exe for functional testing purposes, and I would like to start it sometimes as ASPNETCORE_ENVIRONMENT=Development but other times without that setting.
Why is the difference regarding static web assets serving depending on ASPNETCORE_ENVIRONMENT=Development, and how to run and serve static web assets without that setting from command line?
The question is a bit misleading, as the artifacts in bin/Debug folder is for debugging and not for general testing, so it is not guaranteed to work or supposed to work as you described.
The reason why you found it is not working is because there is no static assets in bin/Debug folder. It works in development environment and not in production (the default when no environment set) because the default builder calls UseStaticWebAssets only in development environment.
https://github.com/dotnet/aspnetcore/blob/4e7d976438b0fc17f435804e801d5d68d193ec33/src/DefaultBuilder/src/WebHost.cs#L221
Inside UseStaticWebAssets, it processes .staticwebssets.runtime.json file to resolve the real path of your static assets. That is how it works and why it does only when environment is development.
If you want to have it works as it supposes to, you should publish your project to a folder and call the executable from there. The publish tool will also publish your static assets into that folder so it will work whether you set the environment config or not.
Okay, I'm trying to publish my Nuxt.js app on my web host but I've run into some issues. I do not want a static site.
After running "npm run build" locally, I transferred the files to my web host with FileZilla. Then I'm supposed to fill in the statements shown in the picture below.
And this is where my problems begin. The app does not want to start at all, and i am nor sure what to put as "Application startup file". And according to my web host, the overall problem is that there is no startup file for Nuxt applications. I am completely new to Nuxt and do not have that knowledge and therefore I now turn to you, is it the case that there is no starup file for Nuxt?
The web host also mentioned that it is more difficult to get a Nuxt application upp and running on shared hosting, is that correct? Will I not be able to get my app up and running in this place?
My web host had received this error message when they tried to start my app. Maybe there are some clues in there to find.
ERROR Request failed with status code 404 15:58:38
at createError ({{my-adress}}/14/lib/node_modules/axios/lib/core/createError.js:16:15)
at settle ({{my-adress}}/14/lib/node_modules/axios/lib/core/settle.js:17:12)
at Unzip.handleStreamEnd ({{my-adress}}/14/lib/node_modules/axios/lib/adapters/http.js:260:11)
at Unzip.emit (events.js:315:20)
at endReadableNT (internal/streams/readable.js:1327:12)
at processTicksAndRejections (internal/process/task_queues.js:80:21)
Hope someone can help!
Without some more context, I can't tell you exactly what your issue is but I suspect it is to do with how the web server on your shared hosting is configured to serve files. When you visit a route, it's not correctly finding that index.html page.
A Nuxt static application deploys with a structure where each page route has its own rendered index.html page inside a folder - if I'm not mistaken.
Your web path may look like example.com/hello but in reality it resolves as example.com/hello/index.html. Some web servers will struggle by default with this structure if not setup correctly.
Honestly, if I were you I'd deploy the project to either Vercel or Netlify.
Both have incredibly generous free tiers that will let you host your application for (if it's not making any money) for a very long time at a good scale.
They both run on automatically scaling infrastructure so you don't need to worry how much resources your site is consuming or how many users you get. It will maintain responsive and reliable without any detriment to load speed.
They'll also automatically handle building and deploying the application on your behalf. All you need to do is connect the service to a Github repository.
They also provide CDN's and other optimisations such as compression for you as well to make your site much faster.
Nuxt has a dedicated page on Netlify deployment. I recommend you give it a read:
https://nuxtjs.org/docs/2.x/deployment/netlify-deployment/
When you do npm run build (or npm run generate), your final content will be available in the /dist directory (the console should tell it to you at the end). It contains an index.html file, this is the one that serves as entry point.
Btw, before going any further double check that this is working locally:
npm run build
npm run start (URL and port will be given to you)
If it works locally, you can proceed.
.nuxt is essentially used for development purposes, caching and so on. And should not be tracked by Git, nor deployed.
I'd like to advice against using FTP for deploys (especially if not secured). Prefer a more modern way, like pushing your latest git commit and let the platform handle the hook or fetching your new code and bundling your app for you.
As recommended above, Netlify is one of the best place to easily host your Nuxt app: simple, fast and headache-free. Also, check #jordan's link about the various platform deployments, you may find yours (if it's good/well known).
I may come here a little late, but this is the way I configure the "Application startup file" when deploying a Nuxt app in shared hosting using the NodeJS Selector app (that commonly you find in CPanel)
Since basically the startup file in NodeSelector is executed as if you would run node startup_file.js, you can create an app.js at the root of the project, and add the following code:
require('#nuxt/cli').run(['start']);
This is basically the same as nuxt start, which is basically the start script in your package.json
Hope this can help others having the same issue. I leave here the same issue posted in git:
https://github.com/nuxt/nuxt.js/issues/7192
I have a Asp.Net Core MVC application running on Windows Server 2008 R2 with IIS. But every time I update this application, I need to manually stop the applicationPool in IIS, and restart the applicationPool after I finish updating the app. Otherwise it will tel me "the xxx.dll is in use by other progress".
Is there any way to make this process easier?
A workaround For Windows with no down time and I am regularly using is:
Rename running .NET core application dll to filename.dll.backup
Upload the new .dll (web application is available and serving the requests while file is being uploaded)
Once upload is complete recycle the Application Pool. Either Requires RDP Access to server or function to recycle application pool in your hosting control panel.
IIS overlaps the app pool when recycling so there usually isn’t any downtime during a recycle. So requests still come in without every knowing the app pool has been recycled and the requests are served seamlessly with no downtime.
I am still searching for more better method than this..!! :)
January 2022 - for Linux
For Linux, we use Openresty nginx with Lua script to hold (sleep) incoming requests for few seconds until the service running .NET Core or .NET 5 or .Net 6 application restarts and then we release the threads we had hold.
Refer: https://github.com/basecamp/intermission
Finally I found my anwser:
I just need add a file named app_offline.htm to the IIS web root(not your project wwwroot folder), and remove it after you replace all of your file.
due to this issue you may need try both App_Offline.htm or app_offline.htm .
and this will allow you to use FTP client to update
Opening the web.config file in an editor and saving it will cause the web application to reload, even if you don't change anything. All DLLs should be replaceable, until a user hits the site, causing the web application to start again. I sometimes use that as a workaround.
A more full fledged solution would be to use Web Deploy, either through Visual Studio or by command line. This can take a litte while to set up, but offers more automation.
https://learn.microsoft.com/en-us/aspnet/core/publishing/iis#deploy-the-application-1
There is no way to hotswap in place DLL's.
Your best bet is to deploy to a new folder each time (For example a versioned folder), and change the website directory in IIS once you have fully copied your website onto the server.
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.
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.