So begins from 0.75.1, Rebus no longer supports ASP.NET 4?
My question will be:
Is 0.75 a stable release for .NET 4 project?
Are we going to continue get bug fixes (if any) for .NET 4 target project?
Thanks
As of 0.75 Rebus has targeted .NET 4.5, which was a requirement to support the usage of async/await in the library.
I'm not an expert on ASP.NET and whether the version follow the versions of .NET, but Rebus will work as long as your host process targets (at least) version 4.5 of the framework. If ASP.NET 4 is only available for projects that target .NET 4, then that implies that you cannot use versions > 0.72 of Rebus.
And then an answer to your questions:
You should pick the latest version of Rebus, but that requires that you target (at least) .NET 4.5. If that is not an option, you should pick Rebus 0.72 (which is the last version available that targets .NET 4).
No (*)
As for the (*) above, I'd like to make the following fairly long and elaborate point: Generally, you can't count on getting bug fixes for the free, open-source software you have downloaded and are using, freely, without having paid a cent - at all!
If you want to be able to reliably count on getting bug fixes for your free software, I suggest you get a support contract with a company that is willing to provide that service. My employer provides that service for Rebus in case you're interested.
With that said, I'll add that I am a pretty helpful person, and I do a lot for people to have a nice experience with Rebus, but I am sure that you can understand that I cannot promise to provide bug fixes for the old versions.
I will be around for helpful advice if you run into something, but - as I am developing Rebus mostly in my spare time - you can probably understand why I need to concentrate my efforts on the current version.
Related
We're in the unfortunate situation of still having to support a Windows CE based device (ARMV7 architecture). We're continuously running into problems regarding the limited functionality of .NET Compact framework (no security libraries, very limited asynchronous support, ...). Since the .NET Core CLR has been compiled for multiple platforms, including ARM-based platform, the idea of trying to compile it for Windows CE as well came up. I invested about a day to see how far I'd get, however I'm not the most experienced CMake user.
I couldn't find any hint on the internet whether someone ever tried, so... Is there a basic possibility of succeeding in doing so or are there limitations I do not yet see which make getting a working version highly improbable?
I've read some things about .NET Standard and .NET Core, and generally they seem to say something like "This is the new way to do things, and here are the advantages and disadvantages."
What I haven't seen is a good, clear explanation of what was wrong with the status quo, such as .NET Standard and .NET Core were even necessarily. To really judge what I should use these for, it would be helpful to know why they exist at all.
Can someone give a clear (and not necessarily concise!) explanation of (a) what problem .NET Standard and .NET Core are intended to solve, and (b) how they solve it?
.NET Standard is a set of library contracts. Each version includes all the contracts of the previous version - so everything in netstandard1.4 is in netstandard1.5 for example.
.NET Core is an implementation of .NET Standard (and some extra functionality) which runs on Windows, Linux and OSX.
Biggest problems they solve:
Not having a Microsoft-provided/supported toolchain and runtime on Linux/MacOSX. Saying that you could only run .NET-based server code on Windows or Mono was simply untenable.
The Portable Class Library mess with hundreds of different profiles giving partially-overlapping API surfaces to target.
PCLs in particular were very hard to work with for class library authors such as myself. The mess came about because there were multiple efforts to bring a .NET runtime to different devices without enough coordination to provide a coherent API surface to target.
Now multiple vendors can target particular versions of .NET Standard, and anything targeted to that version or higher should work. For example, my Noda Time library targets netstandard1.3. Suppose a new mobile phone vendor comes out with a completely new implementation of .NET, with a completely new kind of application - but says they support netstandard2.0. That's fine - a user of that new platform will still be able to install the Noda Time NuGet package and (implementation bugs aside, of course) they'll be able to use it. I don't need to know that the platform even exists.
I am working on a .NET Core project and I am trying to parse my List<T> to byte[].
Using the .NET Framework, we could have achieved the same by using BinaryFormatter, but at the time of writing this question it looks like Microsoft does not yet support it in .NET Core and no upcoming releases seem to do that.
Can anybody tell how to perform this serialization in .NET Core?
Also, is binary serialization platform-dependent, and for such reason been deprecated in .NET Core?
You can use Binaron.Serializer - https://github.com/zachsaw/Binaron.Serializer
There's no need to decorate your class with any attributes.
Disclaimer: I'm the author of Binaron.Serializer.
You can use MessagePack. The package is chosen as Package of the week in .Net blog.
Nuget command:
Install-Package MessagePack
You can also take a look into their source code and see how it is implemented in .net core.
.NET Core 2.1 now includes a BinaryFormatter you can use for this.
You can find more details in this answer.
BinaryFormatter is getting obsoleted in the upcoming .NET versions due to its security flaws.
It is basically safe only if both serialization and deserialization happens in the same process (which is not the case in most scenarios) so it has been decided to remove it from future versions.
Though the obsoletion document says that in .NET 8 the complete binary serialization infrastructure will be removed I still hope this can be somewhat influenced. I recently opened an issue to discuss the possible ways of making binary serialization (and any polymorphic serialization) safe: https://github.com/dotnet/runtime/issues/50909
But as the other answers also illustrate, there are many custom binary serializers you can choose from. #ZachSaw's Binarion or MessagePack are equally popular, and I also made my binary serializer public a few years ago (NuGet). It tries to address the security aspects and good performance (meaning both speed and size).
But frankly, when communicating between remote entities (including file and database sources), a vulnerable binary serializer never should be used. And even the speed of the slower text-based serializers will be still much faster than any network communication so their speed barely can be real bottleneck.
For payload size and performance you can try BOIS which focuses on packed data size and provides the best packing so far. It also supports .Net Core
https://github.com/salarcode/Bois
Okay today, as most of you noticed Framework 4.0 has been released. I've been working on a project which is being built on framework 3.5. Since I want to use dynamic keyword and most of the asp.net features like Tableless Menu Control, ClientIDMode and clean web.config etc. I am kinda urging to migrate the unfinished project to 4.0 but I am little hesitating about that.Some times I think it is way better to wait for SP1.
So what do you think about it? You guys will migrate to unfinished projects or will still hang out with 3.5 for a while.
Thanks.
The .Net 4.0 runtime environment has been out for a while (mind you not RTM, but RC1 and so forth). A lot of people have tested it and I would guess that almost all of the bugs have been shaken out. There should be no problem switching at this point. They have introduced a number of items that improve .Net. Are they necessary, no, but they can make programming in .Net easier.
You can always download 4.0 locally and test it out on your project. Worse comes to worse, the project blows up and you reload it from your source control system.
What you should be aware of is that there are breaking changes in both C# and VB.Net in 4.0 runtime environment. You'll need to watch out for those.
The following probably applies to most framework-base development.
Do the new features save more time than fixing the old things the upgrade breaks?
If you're going to waste lots of time making old things work, perhaps you're better off just to sit it out on 3.x and port to 4.x at a later phase.
If you really need features from 4.0 and would have to spend time implementing them yourself, perhaps it's a net time saving.
Can you support this version of the framework? (ie can your server people handle the upgrades and monitor things okay?)
If your server bods can't make this work in the field, give up now. I don't know your organisational structure or who runs your servers but I know some companies have a pretty thorough testing regime they'll put software through before allowing it. As a brand new version, they might be weary.
And let's be frank, just because something goes through several pre-release versions, they don't catch every bug because they're rarely used in production scenarios. You know the drill.
And if installing 4.0 on the server breaks old things, you might be waiting a long time.
Is your project's launch likely going to be after the first round of bug fixes?
If you're developing this for 3+ months away, you've probably got enough time to sort the platform issues, fix the code issues and get framework bugs reported with the (blind) hope that they fix them or you can work around them safely.
If you're launching tomorrow, it's not enough time to test it.
I will only upgrade when there is a need to do it. For example I have one application that must use features delivered in .Net Framework 4. So that application will get upgraded ASAP.
I have another application that is 3.5 with no driving need to upgrade at this time. That one will get upgraded when time and budget allows.
I am preparing to start on a new short-term contract (1-2 months) that involves replacing an Access application by moving it to ASP.NET and SQL Server.
I am only responsible for the ASP part and connecting it to the database.
The only requirement is that whatever technologies I use be relatively well-known in the area, so that if they need to have someone else work on it, it isn't specialized knowledge.
So, I could do this in Rails or ASP.NET, but, when should the development be aiming for .NET 4 Framework, as there are many changes coming out that may be advantageous to use.
Or, even though it may be useful, when is it better to just ignore new features and stay on an older version of .NET?
I am assuming that hardware isn't the limitation, as many computers won't be able to run .NET 4 Framework, but that would be an issue for a hosting company, as they can find a hosting company to support whichever framework the application is designed for. If Rails makes the most sense, as their hope is to have the application written quickly, but have it reliable, then again, the hosting company would need to support it, or they use a different one.
This company hasn't used a hosting company, they need to find one, so there isn't a relationship that could be an issue.
UPDATE: Part of my concern is that initially the application will not require javascript, but phase 2 will be to make it more interactive, as some clients won't be allowed to have javascript on their computers. In order to limit how much javascript must be known by a developer there are frameworks that will adapt to browsers and situations fairly well, which is why I am also thinking about RoR and the fact that there appears to be changes coming out in .NET 4 that may help with this.
As a general rule of thumb, I wait one year before building sites in a new framework unless the client specifically asks for the newest technology. This has worked out very well for me. The advantages are:
The technology is much more stable (hotfixes, service packs, etc.)
Common complaints about missing functionality are usually resolved
Hosting companies, support communities and corporate IT departments have had time to get used to the technology, find out more about it, play around with it and have it mature within their organization
Unless there is specific need for new functionality introduced by .Net 4, there is no point in subjecting your clients to the immediate problems with an initial release, or making it more difficult for them to find hosting. You should either investigate all of this up-front, or use .Net 3.5 in the meantime.
The only requirement is that whatever
technologies I use that it be
relatively well-known in the area, so
that if they need to have someone else
work on it, it isn't specialized
knowledge.
I would have thought that requirement was enough not to develop this project on .NET 4.0 - it takes time for a new framework version to filter down into the market, and it will be a while yet before there are a lot of developers around with .NET 4.0 experience.
Also, you would be essentially developing on top of a BETA product - while I'm sure most of the features will remain unbroken from BETA -> RTM, there is always a risk that something will break or not work like it did in BETA, so why risk this on a commercial project?
I wouldn't target .NET 4.0 yet on a commercial project unless there was a specific reason for doing so, and even then you would have to have buy-in from the client, ie "I can do this much more quickly and with less effort if we use the current beta version X rather than established, stable version Y" - good luck with that.
I worked on a commercial project that used the CTP version of LINQ to SQL - then when we went to VS2008 / 3.5, suddenly everything changed and we had to make a lot of changes just to get LINQ to SQL working again.
Stick with 3.5 - it's easier for hosting and getting developers.
Just a couple of thoughts, I wouldn't even think about creating an application for production use in .NET 4/ASP.NET 4 until:
There is a release candidate. It's
not the first time I've seen
features in beta's not make it to
RC/RTM.
Microsoft have permitted development and deployment
of production applications by way of a 'Go
Live' license.
There are some hosters out in the market such as OrcsWeb who are participating in public beta testing, but they aren't intended for production use.
I'd run with the .NET 3.5/ASP.NET 2.0 or MVC bits for now. Better safe than sorry.
Generally speaking it's going to be easier finding hosting for a Rails app. If you want to run .net 4.0 you're probably going to have to run a VPS or dedicated machine. However if you're bailing after the application is finished and assuming your client is in Knoxville, they're going to have a tougher time finding a Rails developer to maintain the application.
I think the bigger question is your role. They're looking to you to solve this problem for them. Are you productive in both technologies? How about getting a Windows server up and running? A Linux server? How's your SQL Server vs MySql? I'd guess that you're probably stronger on one stack vs the other - for a contract that short I wouldn't want to be doing a lot of experimental development.
i wait until the OS that everyone will be using has it.
Just last month i took a dependancy on GDI+, which first shipped with Windows XP.