0

This may seem incredibly basic, but I'm trying to understand access to namespaces that are not directly referenced in a .csproj file and do not include paths to or .dlls in the bin.

From my understanding, mscorlib is included in every .Net application at compiling, and grants the application access to all the namespaces it includes. This would mean that if the namespace is included in mscorlib ("System.Runtime" specifically) then it does not need to be directly referenced via in the project file for the application to still have access to it, correct?

Also, this application is on an Azure Web App, which from my understanding doesn't support a GAC, which I know is one way mscorlib is sometimes accessed. The reason this popped up is I have seen several versions of a project file, some with System.Runtime and System.IO referenced in the .csproj file and some without them, and both appear to be working fine and I just want to know how that's possible.

Thanks!

WO101
  • 1
  • 1
    References are for *assemblies*, not namespaces. Classes have namespaces, and they can (in principle) be present in any assembly they like (and some namespaces, like `System`, are split across assemblies this way). The location of classes can differ based on the .NET Framework. For example, [`System.Runtime.GCSettings`](https://learn.microsoft.com/dotnet/api/system.runtime.gcsettings) lives in `mscorlib` on the .NET full framework, but in `System.Runtime` on .NET Core (note the "assemblies" line). There are NuGet packages with special assemblies that sort out these differences. – Jeroen Mostert Aug 02 '18 at 20:29
  • @JeroenMostert thank you so much for the help. I know this must be incredibly basic, I'm just trying to sort it out. The application is currently targeting .Net v4.6.2. I guess where I get really confused is how the System.Runtime and System.IO assemblies are referenced via and in some versions of the project file and not in others, yet both compile correctly. I just assumed if it was necessary for the application to function, it wouldn't work if that assembly reference was removed unless it could be accessed elsewhere – WO101 Aug 02 '18 at 21:40
  • Well, for starters, if no type is ever referenced from these assemblies there'll be no error. (On .NET full, `System.IO.Stream` lives in `mscorlib`, for example, so whether or not there's a `System.IO.dll` to reference won't matter.) To complicate matters further (so no, this isn't as incredibly basic as it sounds, don't worry) if your project uses the .NET Standard way of including references, then these differences between platforms are papered over by standard assemblies (so there will be a `System.IO`, but it just forwards the types to `mscorlib`). – Jeroen Mostert Aug 02 '18 at 21:50
  • Overall, with the introduction of .NET Core and the unifying force of .NET Standard, references haven't gotten easier. For developers, the experience is still pretty easy because, for the most part, you can just add in a NuGet package named after the namespace you're after, and it will sort out exactly what assemblies should get referenced on the platform for which we're building. – Jeroen Mostert Aug 02 '18 at 21:52
  • @JeroenMostert you're a hero for helping me work through this. I believe it's using .Net Framework 4.6.2 (full?) So the fact that it's compiling in VS2017 without those references in the .csproj mean that either no type from the assemblies is ever used, or that the namespaces those assemblies would be referencing are coming from mscorlib instead? From my understanding mscorlib and everything in it is included automatically in all .Net builds. This was kind of my assumption but I thought it strange that the original .csporj file for Sitefinity would have those referenced if they weren't needed – WO101 Aug 02 '18 at 22:07
  • @JeroenMostert also, in this particular case there appears to be a bug that impacts these 2 particular references, and it's reported "Opening a project in Sitefinity with Visual Studio 2015 the following references appear unresolved : System.IO, System.Runtime, System.Threading.Tasks, System.Web.Http.SelfHost. The project was built in VS2015 so we're wondering if that is how or why these were removed. There are a few copies of the same code on the web and 1/2 have references to System.Runtime and System.IO in the .csproj file and 1/2 do not. – WO101 Aug 02 '18 at 22:16
  • `mscorlib` is included as a reference by the C# compiler even if not specified, unless explicitly excluded with the `/nostdlib` option, which is an advanced option that's normally only used by people doing very interesting things. So yes, normally you'll be able to reference everything in `mscorlib` (which includes lots of types across lots of namespaces) without doing anything else. But many modern ASP.NET sites use .NET Core or target .NET Standard (so they can run both on .NET Core and .NET full) and then relying on this implicit `mscorlib` would not do. – Jeroen Mostert Aug 02 '18 at 22:16
  • @JeroenMostert here is the full bug report: Here is the full bug report: https://knowledgebase.progress.com/articles/Article/unresolved-project-references-for-system-io-system-runtime-system-threading-tasks-system-web-http-selfhost Also, is there a way to identify if this particular site is using .Net core or .Net standard? In the project file, I keep seeing references to targetFramework="4.6.2" which is why I'm assuming it's .Net Framework. Under assembly references I do see "mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" – WO101 Aug 02 '18 at 22:23
  • @JeroenMostert seriously, thank you for this. I also see assembly: TargetFramework(".NETFramework,Version=v4.6.2", FrameworkDisplayName = ".NET Framework 4.6.2"), so looks like that means it's using full, correct? – WO101 Aug 02 '18 at 22:25
  • A new-style project file (the kind used by .NET Core and .NET Standard) will have a `` or `` tag including the framework(s) it's building for (for example, `net462` to target .NET 4.6.2); [see also](https://learn.microsoft.com/dotnet/standard/frameworks). It sounds like you've got a traditional project file on your hands, and those only target .NET full anyway. – Jeroen Mostert Aug 02 '18 at 22:28
  • Yea, I believe that must be correct, I only see v4.6.2 in the .csproj file, and the above version in the assembly list. That being the case, we can assume that the 2 reference missing from the .csproj file: System.Runtime a System.IO are both being satisfied by mscorlib since the reference has been removed from the .csproj file? I see both the namespaces listed in mscorlib – WO101 Aug 02 '18 at 22:36
  • It's more likely that VS 2017 resolves these things from the GAC, and Azure resolves them from wherever it is that Azure pulls system assemblies from, because `System.Runtime.dll` [*does* exist in .NET 4.5 and beyond](https://stackoverflow.com/q/22822406/4137916) (though I couldn't immediately tell you what types live in there now, as opposed to `mscorlib`). If the project asks for a reference, then the reference must still be satisfied. But it is not possible to tell if the project actually *uses* the types in those assemblies -- if it still works without them, then apparently not! – Jeroen Mostert Aug 02 '18 at 22:43
  • @JeroenMostert I think you're right. The GAC is another puzzle I ran into during this process, and maybe if I understood it that would have solved my question. I read that Azure Web Apps do not support adding to the .GAC without blobs. If an assembly is located in the GAC through VB2017, would that be transferred to the server during compilation, or would the server also need the same file in the GAC? It is good to hear that if the project is compiling and not throwing errors, it should be fine. Azure does have .Net versions installed on their web apps so maybe those files act as the GAC there – WO101 Aug 02 '18 at 22:56

0 Answers0