I want to use interface IHeaderDictionary (or the class HeaderDictionary) in a class library. It is an interface defined in ASP.NET Core which represents a collection of http request or response headers. We have some classes working with it in a separate git repository and we want to define a contract separately in a yet another separate git repository. So I have a tiny C# project and there is only a contract in it, nothing else.
The question is this: Which nuget should I reference to be able to use IHeaderDictinary in my contract?
MSDN says it is defined in nuget Microsoft.AspNetCore.App.Ref. And it is really there, but it is forbidden to reference that nuget. (It has package type DotnetPlatform which effectively prevents it to be included in regular class libraries, as mentioned in other discussions.) But which nuget should I reference if not that one? I tried to reference Microsoft.AspNetCore.App, but it is a framework one, so it cannot be referenced too. Then we found that in an older application we used this interface from nuget called Microsoft.AspNetCore.Http.Features. And it works, I can still use this one but when I look to nuget gallery, I can see it is an abandoned nuget, the latest version is 6.0.0-preview, so apparently this is not the correct way how Microsoft intended us to use IHeaderDictionary.
So what am I missing here? Typically, authors of nugets provide something like "contract" or "abstractions" nugets which are tiny and can be included in other contracts. Please help me to understand what is the problem with ASP.NET and how to use it in contracts.
Related
When I register a .NET assembly enabled for COM interop using the REGASM tool, the tool creates a separate registry key for each component version. For example, I get:
HKEY_CLASSES_ROOT\CLSID\{myCLSID}\InprocServer32\1.0.0.0
HKEY_CLASSES_ROOT\CLSID\{myCLSID}\InprocServer32\1.1.0.0
etc.
Each of these registry contains roughly the same structure values as it is under HKEY_CLASSES_ROOT\CLSID{}\InprocServer32, except that the entries point to different locations, depending on the component version. The HKEY_CLASSES_ROOT\CLSID{myCLSID}\InprocServer32 apparently contains the latest registered version, and that's what COM consumers will normally use, of course, and they ignore the rest.
This structure apparently allows different versions of the component coexist on the same computer (I know it is against the originally specified COM rules). I would like to use it, but I could not find any documentation about it anywhere in the Microsoft documentation or Googling for it. Does anybody know? I am looking for something like CoCreateInstance/CoCreateInstanceEx with the version specifier.
Thanks
ExcelRichTextHtmlUtility does not appear in the EPPlus 4.5.1 library (or 4.1 for that matter). I see it's in the code in source control but doesn't get shipped I guess. Is there a particular reason or maybe I'm doing something wrong.
It's in the source code but not compiled as part of the project anymore. When I include ExcelRichTextHtmlUtility.cs, the following line does not compile:
s = System.Web.HttpUtility.HtmlDecode(s);
In taking a look at the project settings, EPPlus targets the .NET 3.5 Client Profile framework. The Client Profile is a subset of the framework which for example does not include System.Web, so HttpUtility cannot be used so they must have just simply excluded the class.
I couldn't find any reference to exactly when and why this was changed so this probably does not completely answer your question.
For example this happened to me when I added configuration (IConfigurationRoot) in the Startup.cs file, to be able to access appsettings.json file which has a connection string.
So the first time I write IConfigurationRoot it is obviously marked as not recognized, so I put my mouse over it and expand the Visual Studio suggestions from the light bulb, which are:
using Microsoft.Extension.Configuration:
Microsoft.Extension.Configuration.IConfigurationRoot
Generate Type
Add package Microsoft.Extension.Configuration.Abstractions 1.1.0
So if I pick "using Microsoft.Extensions.Configuration",a using directive is added at the top of my file and VS recognices IConfigurationRoot, everything works fine. But checking the References in my project, this library was not added to it:
No Reference Added
So if instead of picking the using directive, I pick "Add package Microsoft.Extensions.Configuration.Abstractions 1.1.0", Visual Studio also adds the using directive but additionally it adds a new Reference:
Reference Added
I'm not understanding why this happens, why adding the using directive (first suggestion) works fine, is it because the reference is already contained in another library?, if so, why should I add the package individually?. Is it better to add it individually?, what happens if I do, am I adding a reference to the same library twice?
Thanks in advance.
...is it because the reference is already contained in another library?
Yes, look under the Microsoft.Extensions.Configuration.FileExtensions or Microsoft.Extensions.Configuration.Json and you eventually get to the Abstractions package.
If so, why should I add the package individually?
There is no need. The light bulb tooling might not quite up to speed with the whole package dependency stuff.
Is it better to add it individually?
Not really, but if your ever removed some of those base package then adding it individually from Nuget would ensure that it would remain.
What happens if I do, am I adding a reference to the same library twice?
In an indirect way, yes, but there's no harm. The Dependency tree view drills down into each layer of dependencies. You will see lots of "duplicates" if start expanding those nodes.
I am trying to use the generic DbSet class. I have tried adding the following references so far to my solution because the MSDN documentation states that DbSet lives inside System.Data.Entity:
However, as shown below I still cannot add a reference to System.Data.Entity, the only suggestion intellisense has is EntityClient which does not contain DbSet:
Resharper/Intellisense is not giving me any other suggestions of namespaces I could possibly add.
I have tried cleaning and rebuilding my solution, and I am using the .Net Framework 4 full version (not the client version).
I have tried using NuGet to search for EntityFramework and have found one result which I have added to no avail as is show below:
What DLL file do I need to add to my solution to add a reference to System.Data.Entity and use the DbSet class?
Thanks
The same MSDN reference page that you mention says that you need to reference EntityFramework.dll in your project.
Note that namespaces and assemblies are not the same thing. The following statement is a little over-simplified, but you can think of namespaces as residing inside (or becoming available by referencing) an assembly.
So, once you've referenced the assembly, you will still need the using System.Data.Entity; directive.
I tried validating an XML file via the XDocument.Validate method defined in System.Xml.Schema.Extensions. However the compiler says that XDocument “does not contain a definition for ‘Validate’ and no extension method ‘Validate’ of type ‘System.Xml.Linq.XDocument’ could be found”.
Is the System.Xml.Schema.Extensions class really missing from MonoTouch? And if so, is there any other way to validate an XML read into a XDocument?
edit:
The class in question seems to be missing from Mono as well, according to their documentation. Is there any replacement?
MonoTouch is based on the Silverlight profile. Neither Silverlight nor WinPhone7 include System.Xml.Schema.Extensions.
Fortunately, Mono is open source, so you can take the code you need and add it to your project:
https://github.com/mono/mono/blob/master/mcs/class/System.Xml.Linq/System.Xml.Schema/Extensions.cs
Extensions appears to be new in 3.5 - MonoTouch is core 2.0, with bits of later versions (ie, LINQ) included.