Is is a bad idea to have misc files sitting in bin directory

I have an assembly that contains a function that could be called from IIS or from a console app.

Because of this I have opted for the following to get the path:

System.IO.Path.G开发者_StackOverflow社区etDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location)

obviously this will return the bin directory in the case of the function being called from IIS.

I intend to create a txt file on this path. Is it such a bad idea to have text files sitting in the bin directory? Please give valid objections (if any) why this could cause problems.

---

Assembly.Location can return surprising results, e.g. if shadow copying is turned on (for instance, when running through NUnit), or when running from a location not on the local file system (you can run .NET apps over HTTP).

AppDomain.CurrentDomain.BaseDirectory is a safer option, as it returns the original path prior to shadow copying (although in the case of HTTP deployment I think it returns the directory where ieexec.exe is located).

The safest option is to embed whatever data you need as a resource within the assembly, and use Assembly.GetManifestResourceStream to access it at runtime.

---

You simply may not have enough permissions to write to this directory. Try using TEMP folder instead (think Path.GetTempPath()).

---

If you delete/copy/overwrite files in "bin" directory, the IIS will restart processes - because IIS thinks the application was changed, so new requestes should be proceeded with "new" appliaction.

So, yes it is bad idea.

---

Tim Robinson's got the right idea.

The only other thing I should say is if ASP.NET is writing the file, be careful with your threading code; maybe two requests for the same page will try to write the same file at the same time, so just be careful to lock your writes to the file.