0

I had a bad experience with writing data to sub folders in the bin folder containing all app DLLs but this was for ASP.NET MVC hosted in IIS. That kind of writing somehow triggered the reloading (or maybe recompiling) the DLLs and caused a hidden slow performance (such as when writing log data for each request). I had to spent hours configuring out the cause and worked it around by putting the logs folder one level upper (to the same level with bin folder).

Now when working with ASP.NET Core (and especially hosted in docker container), I'm not so sure if that's still the case. Really putting all application data or log files in sub folders is very manageable and convenient for me. It's also easier to configure the paths (using relative paths), the default base path is always the one containing all app DLLs. So we can have a nice directories graph like this:

- dll file 1
- dll file 2
…
+ Logs
      - log1
      - log2
+ AppData
      - …

Especially when hosted in Docker containers, it seems that we should not go up 1 level to save data because all files are put in a folder called app which is already located in the root level of Linux files system. All the app's files should be put in that folder (as a conventional hint). I understand that the original issue I concern about is caused only by the IIS (no matter ASP.NET or ASP.NET Core), which means it would be fine when hosting the app in Docker containers?

halfer
  • 19,824
  • 17
  • 99
  • 186
Hopeless
  • 4,397
  • 5
  • 37
  • 64
  • 2
    The main question is: Why the hell do you want that? If you are using docker anyways, for gods sake, write logs to `/var/logs/xxx` as its common practice and upload stuff to `/tmp` or some other folder you set up. Both folders can be linked as volume so you also won't lose the stuff when you deploy a new container. Generally whats not external mounted into the container gets lost when you create and deploy a new container – Tseng Nov 16 '19 at 17:35
  • @Tseng actually for docker it will be fine, but for other hosting methods (such as using IIS), it's a bit strange. I would like to keep it consistent. Also even when I put the files in a sub holder in `app`, I can still bind it to some shared folder in the host machine to help persist data. One more thing about `easy configuration for paths`, I can just write relative paths like `Logs/…` in my configuration files and not something like `../Logs/..` or even `../var/logs/…`. That makes sense on Linux os but so weird on Windows … (the host machine can be either) – Hopeless Nov 16 '19 at 17:38
  • You misunderstood several points. Hope you go through detailed articles like [this](https://weblog.west-wind.com/posts/2019/May/18/Live-Reloading-Server-Side-ASPNET-Core-Apps) There are significant differences between ASP.NET and ASP.NET Core, and a few experiments can reveal them to you. – Lex Li Nov 16 '19 at 18:44
  • @LexLi thanks for the link, still I could not figure out what I misunderstood here (because actually almost what in my question are just questions, not assumptions). From your link, I learn that the ASP.NET Core (hosted with dotnet.exe) is recompiled only if dll files or configuration files are changed, isn't it? (please help me confirm that), so we can safely write other data files (such as log files, ...) to the app folder (or sub folders) without worrying about recompiling or reloading … which will surely slow down the performance? – Hopeless Nov 17 '19 at 17:17
  • @LexLi btw, if using docker, where do you usually put your log files? we need to support both Windows and Linux hosts, so a common solution is preferred (so that we just need one same appSettings file). As I said, it is really convenient if we could put the log files (as well as any other application data files) in a relative sub folder (e.g: *Logs*) right under the app's root folder. (I'm still wondering about the recompiling/reloading issue here) – Hopeless Nov 17 '19 at 17:21
  • "I understand that the original issue I concern about is caused only by the IIS (no matter ASP.NET or ASP.NET Core)" is a typical misunderstanding. App domain reload is strictly a behavior of ASP.NET runtime, as it monitors the folders. So IIS is not the one causing it. ASP.NET Core does not auto reload, unless you use various tricks over the internet (that's what Rick's post talks about). – Lex Li Nov 18 '19 at 15:02
  • @LexLi do you have any official document taking about that? I've found this post https://stackoverflow.com/questions/52204892/reload-asp-net-core-app-when-dll-files-change-bin-deploy talking about the role of `IIS` in monitoring app file changes, still confusing about which (IIS or the ASP.NET runtime itself) plays this role. BTW, this problem is not much related to my original problem asked in this question. – Hopeless Nov 18 '19 at 22:03
  • Due to the fact that Microsoft migrated most documentation to its Docs site, many references are lost forever. Articles like [this](https://support.microsoft.com/en-au/help/307626/info-asp-net-configuration-overview) only ambiguously says "the system". The close relationship between IIS and ASP.NET (old) often confuses people, so no surprise some answers (like the one you referred to) can say "IIS", when they should actually say "ASP.NET". – Lex Li Nov 18 '19 at 22:13

0 Answers0