Is it possible to use the 'DataTable' or 'DataSet' classes in ASP vNext Core 5.0?
When I try to use those classes, I am getting the error:
'The type or namespace name 'DataTable' could not be found'.
This question is a few months old but I see it coming up all the time so I'll post an answer.
As of beta 3, aspnetcore contains only a subset of the System.Data related members, which can be referenced in System.Data.SqlClient, and System.Data.Common. Among the more noticeable items missing from the data libraries are the following: DataTable, DataSet, IDbConnection, IDbCommand, IDbTransaction, and IDbDataParameter and IDataReader.
If you're looking to maintain some abstraction, you can reference the associated abstract classes like DbCommand, DbConnection, DbTransaction and DbDataReader. One thing to note, DbDataReader along with the SqlDbDataReader object no longer support the Close() method. Instead, you'll just call dispose.
I have not heard whether or not these members will be reintroduced in aspnetcore or not, but they don't appear to be in beta 4 either.
aspnetcore is subset of dnxcore and is considered deprecated, one should use dnxcore instead.
As for the DataTables and other related System.Data types, according to this issue they aren't going to include it soon, unfortunately.
Classes DataSet/DataTable/DataRow and everything related to them (DbCommandGenerator, DbDataAdapter etc) are not available in .NET Core 1.0 release (and in .NET Standards 1.3-1.6 specifications as well). This means that ADO.NET was reduced to minimalistic set of low-level interfaces and components (like IDbConnection, IDbCommand, IDbTransaction, DbProviderFactory). At this moment there are no confirmation that DataRow/DataTable will back in future .NET Core releases.
If you're looking for something between low-level .NET Core ADO interfaces and strongly-typed EF Core models - take a look to open-source NReco.Data library that provides alternative implementations for DbCommandGenerator and DbDataAdapter. I'm the author of this library, so you can ask me for details.
Related
my question is easy, I think. In my solution, I used to create different projects, for example, one for data logic (layer), business logic, etc.
Now, I have to create a library not only for my projects but also an SDK for third parties. I'm not sure if I create a PCL library, my third parties can use it in shared projects. In this library, I have to call HttpClient and I should use Refit and Polly.
I read on Xamarin Help that Portable Class are obsolete. Really?
Any advice? Thank you in advance.
PCL were superseded by SCL (.Net Standard) projects.
You can upgrade your existing projects, as described here
For the new projects, just use .Net Standard
I've recently had to look for a C# porting of the Protocol Buffers library originally developped by Google. And guess what, I found two projects owned both by two very well known persons here: protobuf-csharp-port, written by Jon Skeet and protobuf-net, written by Marc Gravell. My question is simple: which one do I have to choose ?
I quite like Marc's solution as it seems to me closer to C# philisophy (for instance, you can just add attributes to the properties of existing class) and it looks like it can support .NET built-in types such as System.Guid.
I am sure both of them are really great projects but what's your oppinion?
I agree with Jon's points; if you are coding over multiple environments, then his version gives you a similar API to the other "core" implementations. protobuf-net is much more similar to how most of the .NET serializers are implemented, so is more familiar (IMO) to .NET devs. And as Jon notes - the raw binary output should be identical so you can re-implement with a different API if you need to later.
Some points re protobuf-net that are specific to this implementation:
works with existing types (not just generated types from .proto)
works under things like WCF and memcached
can be used to implement ISerializable for existing types
supports inheritance* and serialization callback methods
supports common patterns such as ShouldSerialize[name]
works with existing decorated types (XmlType/XmlElement or DataContract/DataMember) - meaning (for example) that LINQ-to-SQL models serialize out-of-the-box (as long as serialization is enabled in the DBML)
in v2, works for POCO types without any attributes
in v2, works in .NET 1.1 (not sure this is a huge selling feature) and most other frameworks (including monotouch - yay!)
possibly (not yet implemented) v2 might support full-graph* serialization (not just tree serialization)
(*=these features use 100% valid protobuf binary, but which might be hard to consume from other languages)
Are you using other languages in your project as well? If so, my C# port will let you write similar code on all platforms. If not, Marc's port is probably more idiomatic C# to start with. (I've tried to make my code "feel" like normal C#, but the design is clearly based on the Java code to start with, deliberately so that it's familiar to those using Java as well.)
Of course one of the beauties of this is that you can change your mind later and be confident that all your data will still be valid via the other project - they should be absolutely binary compatible (in terms of serialized data), as far as I'm aware.
According to it's GitHub project site protobuf-csharp-port has now been folded into the main Google Protocol Buffers project, so it will be the official .NET implementation of protobuf 3. protobuf-net however was last updated in 2013, although there have been some commits recently in GitHub.
I just switched from protobuf-csharp-port to protobuf-net because:
protobuf-net is more ".net like", i.e. descriptors to serialise members instead of code generation.
If you want to compile protobuf-csharp-port .proto files you have to do a 2 step process, i.e. compile with protoc to .protobin and then compile that with protoGen. protobuf-net does this in one step.
In my case I want to use protocol buffers to replace an xml based communication model between a .net client and a j2ee backend. Since I'm already using code generation I'll go for Jon's implementation.
For projects not requiring java interop I'd choose Marc's implementation, especially since v2 allows working without annotations.
I'm using ASP.NET MVC Core RC-2. I have a web project targeting the full .NET framework. I also have a separate class library in the solution, also targeting the full framework.
In the class library, I have a controller, marked with a route attribute. I have referenced the class library from the web project. This assembly references the nuget package Microsoft.AspNetCore.Mvc v. 1.0.0-rc2-final.
It was my understanding that this external controller would be discovered automatically, e.g.
http://www.strathweb.com/2015/04/asp-net-mvc-6-discovers-controllers/
However this doesn't work for me- I browse to the URL of the route and I get a blank page and it doesn't hit my controller breakpoint.
Any ideas how to get this working?
Interestingly, it does seem to work for web projects targeting .NET Core Framework, referencing a class library also targeting .NET Core. But not for a web project targeting the full framework, referencing a standard .NET class library.
Note: this is MVC Core which is supposed to support this kind of scenario without any MVC<=4 routing overrides.
Still an issue in ASP.Net Core 1.0, not sure if it's by design now. Easiest solution is to do this in Startup.cs/ConfigureServices
services.AddMvc()
.AddApplicationPart(typeof(<class in external assembly>).Assembly)
.AddControllersAsServices();
AddApplicationPart explicitly includes the assembly in searches for controllers.
The call to AddControllersAsServices() will add all the discovered controllers into the services collection, and if you put a breakpoint after this line and inspect 'services', you will see in the collection all the controller types which have been found.
You might also want to check here: https://docs.asp.net/en/latest/migration/rc1-to-rtm.html#asp-net-5-mvc-compile-views as the discovery rules are now changed for controllers from RC1.
Also remember to use IActionResult instead of ActionResult!
I believe you are hitting the following known issue in RC2.
https://github.com/aspnet/Mvc/issues/4674 (workaround is mentioned in the bug)
This has been fixed since then but will only be available in next release (unless you are ok with using nightly builds)
I have a solution which has mixed .net framework.
Environment(in solution) : Website 3.5 Framwork
Class Library 2.0 Framwork
another Class Library 3.5 Framwork
I have added another class library with 3.5 framwork to use LINQ to SQL
add new item linq-to-sql and then added reference to website . once I have added this additional classLibrary with linq-to-sql my intellisense is lost. Even it doesn't recongnise txtBox in the markup. I can only include stadard data types like string , int etc..(If I force using Ctrl+spacebar).
Unfortunately there are probably quite a few reasons why this could happen. According to here there is something called "Low-Impact Intellisense" which can be toggled on and off by pressing Ctrl+Alt+Space.
In VS2010 and .NET 4.0, I see the shortcuts in intellisense for adding contracts to my code (Eg cr, crr) but when I tab to add these in, the code (Such as Contract.Requires) does not have the valid assembly so there is no intellisense (The type can't be found basically).
How exactly do I get up and running with code contracts?
EDIT: All the methods exist in System.Diagnostics.Contracts, but I thought that I would be using attributes throughout? Also, there are so many different .dlls for the contracts available!
Thanks
The assembly is just mscorlib - and Contract is in the System.Diagnostics.Contracts namespace.
<plug>
For some more information about Code Contracts, you could buy the second edition of C# in Depth and read chapter 15. (That chapter was available free, but isn't now I'm afraid.)
</plug>
Or of course you could read the docs too, as they're pretty good :)
If you find you're missing the System.Diagnostics.Contracts namespace, it's worth checking that you really are targeting .NET 4 - if you create a .NET 3.5 project in VS2010, that won't have Code Contracts available (without adding an explicit assembly reference, anyway).