It looks like you are developing a DLL for use by other developers. It also sounds like you are trying to create temporary files where you do not know and / or have no control over the environment.
If the above is true, it might be better to create a configuration file (located in the same directory as your DLL) that contains, among other things, a path for use with temporary files. (Or, better yet, use AppSettings in your App.Config or Web.Config application, similar to Log4Net )
If this configuration file is missing, you can try using GetTempPath() , but it most likely fails for ASP.NET (and may not work under other circumstances).
If you were unable to create temporary files, you can try to save the necessary information in memory (using MemoryStream , for example).
If this fails, you can always tell the user to use the configuration file.
In response to your real question, I don’t know how to reliably say which project you are working with. The beauty of .NET is so flexible. Theoretically, you could write a console application that can run as a web server or desktop application or as a Windows service. It can be all three in one.
You can always try to guess, based on the referenced assemblies, the call to the executable (System.Windows probably means the desktop, System.Web probably means ASP.NET, etc.), but it will be fraught with an error. I wrote several desktop applications that link to web assemblies, and I wrote websites that link to desktop assemblies.
But if you put the path in your configuration file, you may not need to know the context ... you will already have the full path you need without using GetFullPath () or MapPath ().
If you really need to distinguish, you can include the setting in your configuration file. The user of your DLL will be able to configure the assembly in the environment in which it is used. If they mistakenly configure themselves ... well ... most software products will not work properly if you configure them incorrectly. The way this happens.
Or ... even better ... if the behavior of certain tasks (for example, finding a path to a file) needs to be changed based on some state unknown at design time, then you can encode your DLL to support dependency injection to allow your user to properly provide necessary functions.