For GCP's Datastore I see two versions of Nuget, not sure what are the difference between, and which one to use when working with .Net Core applications
Google.Cloud.Datastore.V1
Google.Apis.Datastore.v1beta3
The second one does appears to be recently updated though while the sample application at https://cloud.google.com/datastore/docs/reference/libraries#client-libraries-install-csharp using the first one.
Disclaimer/authority: I'm the primary author of Google.Cloud.Datastore.V1, and I'm responsible for the Google Cloud Client Libraries for .NET. So I know what I'm talking about here, but I do have biases :)
You should really be picking between Google.Cloud.Datastore.V1 and Google.Apis.Datastore.v1 - there's no point in using a beta library at this point.
However, Google.Cloud.Datastore.V1 is the preferred library. The differences are:
Google.Apis.Datastore.v1 works over HTTP/1.1 with JSON payloads. Google.Cloud.Datastore.V1 uses gRPC and protocol buffer payloads.
Google.Apis.Datastore.v1 is entirely autogenerated, with our "old" code generation technology. It should work, but it's not as clean as the more recent code generation. Google.Cloud.Datastore.V1 is a mixture of generated code and hand-written code.
The part about the hand-written code is important - that's how we have classes like DatastoreTransaction which is more pleasant to work with than manually keeping track of the transaction ID etc. There are also a lot of conversions and extra methods on protobuf messages to make Datastore easier to work with.
Both libraries should work fine with .NET Core, but Google.Cloud.Datastore.V1 does require a gRPC native library, which currently only works with x86 and x64. Neither library is supported on UWP, Xamarin or Unity at the moment, but there may be some contexts where Google.Apis.Datastore.v1 works for you but the gRPC library doesn't. I would start off by trying to use Google.Cloud.Datastore.V1 though.
I've being trying to find how to connect a Xamarin or Universal app to Akka.net. I'd like to receive notifications from actors directly to the client like Orleans does. I did not find anything like this in the getakka web page. Is something that is not covered by the framework or it's because there are no .net Core libraries for Xamarin and Universal apps?
Regards.
There's no .Net Core support as yet.
Referring to this post by one of the primary owners of Akka.net, specifically half way down
after yesterday’s announcements I’m wondering if the .NET Core roadmap is even valid anymore. We had talked about starting work on Akka.NET for .NET Core in 2016. As of today, I’m thinking that .NET Core probably won’t be ready until much later than that.
... I can’t have that, and I’m fortunate enough to be in a position where I can and am choosing not to. I’m sticking with .NET 4.5.2 until .NET Core is solid.
Although this was dated May last year, I'm not aware of any changes on this front. I may be wrong, however.
I joined a place where they have an application that is written using VS2005 and .NEt 2.0 Desktop application. Reason why they don't want to move is they are not feeling comfortable and they feel it will break a lot. I feel the opposite. There may be lot Security fixes .NET latest version it was not applied to old version. Is there a Security issue here?
I know there are breaking changes but it will take one or two months to sort it out.
Did any one faced same problem. What are the risk here not to upgrade to the latest version.
I understand .NET 4.5 has whole lot of new functionality it will improve programming experience. Since it is a maintenance application is there a benefit of upgrading to the latest version.
NET 2.0 should be secure. The mainstream support for .NET 2.0 has ended on 4/12/2011 as noted here. Right now MS offers only extended support till 4/12/2016, which includes security updates as you can see in the table at: http://support.microsoft.com/lifecycle/default.aspx?LN=en-us&x=12&y=15.
The first thing you can do is change the target platform and test it. I'd be very surprised if it didn't compile right away.
The .NET framework maintains a lot of legacy code to prevent upgrades such as this from breaking, so compilation and run are both unlikely to break, albeit you may get lots of warnings due to Obsolete implementations.
As for the security consideration, consider that one major aspect of the .NET Framework is the reverse compatibility, which means that your application is already running against the newer runtime anyway, depending on the client environment.
As for improvements to the coding environment, note that the newer coding practices require changes to the code, and thus won't simply automatically be taken advantage of, but may offer a way to go back and streamline (both in terms of performance and code readability) older sections of the code. In short, upgrading offers the chance to integrate these newer functionalities, it doesn't include them automatically.
Finally, as mentioned, support for .NET 2.0 has ended, meaning any security flaws discovered won't be patched, making your 2.0 app potentially less secure than a 4.5 one, which gets regular security updates. This is, again, subject to the client runtime, but will prevent a client from running against the possibly insecure 2.0 Runtime.
I am writing public .NET class library version for our online REST service and I can't decide which version of .NET to choose.
I would like to use .NET 4.0 version but such compiled class library can't be used in .NET 2.0 version?
Maybe there is statistic how many developers use .Net 2.0 version?
There's little reason not to use the latest version of the framework. Not only do you get all the latest features and whistles that speed development time, but you also get to take advantage of all the bug fixes and improvements that Microsoft has done under the hood.
The only advantage of targeting earlier versions of the framework is in a vain hope that the user won't have to download and install anything in order to use your app. But that's far from foolproof, and mostly in vain. Remember that Windows is not a .NET Framework delivery channel and you can't reliably assume that the user will have any version of the .NET Framework installed. Even if you insisted on counting on it being bundled with Windows (which you shouldn't), lots of users still haven't upgraded from Windows XP. Even if you counted on it being pushed out over Windows Update, there are significant numbers of users who either don't use Windows Update, don't use Windows Update very often, or who live out in remote areas with poor/slow Internet access and can't download all of those updates.
The moral of the story is that you're going to have to provide the appropriate version of the .NET Framework with your application anyway. And the .NET 4.0 runtime is actually significantly smaller than the previous versions, so there's little reason to target them. The team has worked really hard on that, and their efforts have really paid off. Even better, as atornblad notes, most apps can target the Client Profile version of the framework which trims out some infrequently used pieces and slims things down another ~16%.
Additionally, I strongly recommend using a setup application that handles installing the required framework for the user automatically and seamlessly. Visual Studio comes with built-in support for creating setup applications, or you could use a third-party installer utility like Inno Setup. That makes using the latest version a no-brainer.
Everyone else seems to be recommending using the latest version, so I'll buck the trend and suggest 2.0 if you don't actually need any features from later versions... if this really is a client library and you have no control over and little idea about who is going to use it.
It really does depend on who your users are likely to be, which in turn depends on what the REST service is. If it's some sort of social media thing, then I'd say it's more likely that your clients will be in environments where they can use .NET 4. If it's something which might well be used by financial institutions or other big businesses, they may well not have the option of using .NET 4, so you should consider earlier versions. This is the approach we've taken for Noda Time where we believe the library will be useful in a wide variety of situations, and we can't predict the client requirements.
Of course, if you know all your clients and know they will all be able to use .NET 4, then go with that.
The big downsides of sticking to .NET 2.0 are that you won't be able to use LINQ internally (unless you use LINQBridge or something similar, which adds another dependency for your library) and you won't be able to (cleanly) provide extension methods. If you can usefully expose more features to the client if you use a later version, you may want to provide multiple versions of the library - but obviously that's a maintenance headache.
Another consideration is whether you ought to provide a Silverlight version - which again depends on what sort of service you're providing and what sort of users you're expecting.
If you are making a REST service you should probably use 4.0.
The only time you need to consider using a legacy version is if another project should reference your compiled dll. The REST service is exposed using HTTP over internet and the client will not use the .dll directly. Or did I understand the question wrong?
It's almost always is a good idea to use the latest version, cause MS provides a lot of bugfixes and innovations in those.
If, in your system, there is a limitation for 2.0, I'm afraid you need to use that one, cause you need to "make the stuff work".
For versions approx destribution, can look on this SO answer (but it till 3.5 version)
When you do not create your library to fit in an existing legacy environment you should always use the most up to date releases.
If I don't understand you wrongly you're looking to create a .NET-based client library to work with some REST service(s) made by you too.
Perhaps you want to provide a client library which can be consumed by 2.0, 3.5 and 4.0 applications, and this is absolutely possible, and using best features of each framework version.
Maybe there're more approaches, but I'd like to suggest you three of them:
Conditional compilation-based approach. You can implement your classes using a common feature set found in legacy and newer framework versions, but take advantage of useful features present in each version. This is possible using conditional compilation and compilation symbols, since you can define specific code to be compiled depending on target framework version (check this question: Is it possible to conditionally compile to .NET Framework version?).
Symbolic links in Visual Studio 2010-based approach. You can choose to use a common feature set, keeping in mind that this is going to be the one found in the oldest version. That is you can create a project which compiles in 2.0, and others for newer versions, adding all compilable files and embedded resources as symbolic links in these Visual Studio projects. This is going to produce an assembly for any of supported framework versions. You can mix conditional compilation-based approach with this one, and you can get a great way of delivering your public assembly in various framework versions in a very reliable and easy-to-maintain way. Note whenever you add a new compiled file or resource to a project, you need to create the corresponding symbolic links for it for your other projects. Check this MSDN article if you want to learn more about linked files: http://msdn.microsoft.com/en-us/library/9f4t9t92.aspx.
Version specific, optimized assemblies. Maybe the most time-consuming approach. It requires more effort, but if your REST service isn't a giant one, you can have room to develop an specific assembly for each framework version, and take advantage of best features and approaches of all of them.
My opinion
In my opinion, I'd take #2 approach, because it has the best of #1 and #3. If you get used with it, it's easy to maintain and it's all about discipline, and you'll have a good range of choices for your client developers.
I'd compromise and use the oldest framework that provides you (the library's author) the most bang for your buck. It's compromise that lets you develop the fastest and exposes your library to the more users. For me, that usually means 3.5 because I tend to use LINQ extensively.
It should be trivial to provide both 2.0 and 4.0 binaries, as long as you're not using any of the 4.0 specific dlls.
You can also publish your client library source code - .NET binaries are already so easy to decompile that you're not leaking out anything valuable this way.
Any one has recommendation, links to how to migrate workflow 3.5 to 4.0?
Any issues to look for, does MS provide some tool to facilitate migration? Or the only was is to re-write the whole thing ....
There is a migration toolkit on CodePlex here. There is also an Interop activity in the box so yu can use some WF3 activities in WF4 as is.
That said WF4 is a completely new codebase with a very different design and migration is, in most cases, not a realistic option.