How can I integrate the SignalR references and Dlls into a 3.5 project ?
Three options:
you don't use it
you upgrade your project to a more recent framework (presumably 4.5)
you do the work to make SignalR work on .NET 3.5, possibly submitting a pull request
The web world moves rapidly; .NET 3.5 was released in November 2007 - over 5 years ago. Forcing all library authors to restrict themselves to this, when the vast majority of projects are going to be for 4.0 / 4.5 is prohibitive. Some projects may choose to do this, some may some may offer a restricted subset of features on older platforms, and some may elect that it simply isn't worth the overhead to support (a lot of effort, to support a marginal and declining user base).
Frankly, I think you should treat this as a reason to consider upgrading framework.
In particular, I can imagine SignalR wanting to make use of the WebSocket and improved async IO features, the MVC hooks, plus the http-context stubbing features (for unit tests). But possibly a lot more (I haven't checked).
Related
I was about to use the existing Serilog's SQL Server sink but I realized that the latest pre-release and stable versions do not support ASP.NET Core.
Is there an alternative to this sink? What am I supposed to do? Should I write a new sink?
The Serilog sink for SQL Server depends on some types not yet in .NET Core. Work started to refactor the sink and remove the dependencies, but since then, the types in question have been added to the next .NET Core version:
https://github.com/dotnet/corefx/pull/12426
Due to this, the Serilog SQL Server sink will most likely remain .NET Framework-only until the next .NET Core/.NET Standard release, after which support will be quick to add.
In the interim, writing a quick implementation of ILogEventSink of your own would be a reasonable way to get unblocked.
I can't tell you what you're supposed do, but I can describe a couple options. The Sql Server Serilog provider on GitHub would be a better place to ask the question of what they intend to do.
Serilog is indeed on the .Net Core train, as many, many other mainstream .Net projects are. You are correct that as of today, the SQL server sink is .Net 4.5 only. You can:
Continue developing your ASP.Net Core project, target .Net 4.5 in your project json, build and deploy to windows OS only, but carry on using SQL server sink.
Many companies are migrating to .Net Core but targeting .Net 4.x.x in order to keep 100% back compatibility with existing packages while the kinks are ironed out in the framework. This has been a viable solution for my large scale projects.
Target .Net Core, and write your own logging repository layer to manage custom SQL and database log dumping code.
If you're in core, this is easier than it sounds, but requires experience with Data Repositories and IoC. Any code that needs to dump logs to the database would have to have some sort of "ILoggingRepository". It does however, duplicate calls to logging methods, in addition to deviation from the ILoggerProvider interfaces in Microsoft.Logging.Abstractions - forgoing the flexibility of log levels and such, unless you decided to re-engineer your own. It's a working solution; I never said it was an elegant one.
Write your own Serilog sink.
I don't have experience with this one, but I have seen code samples that describe details of how to accomplish this. The reason I never pursued this option is due to a fear that by the time I finished writing my beastly database sink, the open-source community would rework the Sql Server version into a fully core-compliant and database independent version. This would be the most heavy-handed solution, but also the most robust.
There may be other sinks available for .Net Core, but if you're looking for the SQL server one specifically, then you most likely are working with constraints that prevent using MongoDB sinks and file providers and such.
I guess the question is not really technical, but rather a philosophical one, then I do not propose an answer, but consideration:
In my humble opinion, Microsoft with its Silverlight killing, UWP orientation and "escape to clouds", admitted defeat of its entire concept of proprietary software development, so liberation of dotnet platform is nothing more than the farewell gift for developers, deceived in their hopes.
By itself, dotnet ecosystem is very promising, but its future has little to do with the Microsoft products, as it was before. At least, I hope as a developer who has been working with Microsoft products more then twenty years. Therefore, common infrastructure libraries that were focused on concrete Microsoft products (I mean MS SQL Server in this current case) are dying now.
Therefore, the conclusion is: if you already have long-term project that tightly coupled with SQLServer, maybe it is better to put some efforts to your current logging solution adaptation, otherwise it is better to look for some logging solution, not dependent on MSSQL. Probably it should support different storages via adapters or something like that.
Try to look at this, they declare Core support in next version, at least this is a live project.
I've seen questions and answers about why .Net framework 3 or 3.5 or 4 are good. But I've got an app that compiles well in all of these versions including 2. I was curious to know whether there would be a problem if I compile my app with .Net 2 and distribute it. (Version 2 is natively suuported by many versions of windows.)
Is there a performance or speed issue with the older versions or something that I should know of?
Many Thanks
No, there's no problem continuing to use .NET 2 if you want to.
To my mind the principle benefit of using .NET 3.5 would be that you could use LINQ (without extra libraries such as LINQBridge) which may well make your code simpler.
.NET 3 and .NET 3.5 were additions to .NET 2, so there shouldn't be any performance difference - with the caveat that .NET 3.5 came with .NET 2.0 SP1, so there were a few modifications... but if you run a .NET 2.0 application on a machine that has .NET 3.5 installed, it'll be running the SP1 code anyway, so it makes no difference whether you've actually targeted .NET 2.0 or 3.5.
well,not really.
If your app runs on 2.0 then it can also run on 3,3.5 and 4.0 since they are backward compatible.
If you get along with 2.0 then compile for 2.0 there is no reason to artificially raise the requirements.
However if you are not using any 3.0+ features I would recommend you to learn about all the new features. It will speed up your development and improve your code.
How far back does the argument hold? If the original question had asked why go with 3.5 or 4.0 if 1.0 works would the answers be different?
At some point there's risk in clinging too long to an out of date platform. You might still be okay with 2.0, but 2 versions behind might be as far as I'd push it.
I think it really depends on your use-case.
Is this app:
A client you deploy to all sorts of windows clients (e.g. consumer-type win app)
A client you deploy to your enterprise (and they'll manage .net versions)
A server-side app on your data center
A server-side app you sell and others install
etc.
If it's #1, then you want to target .NET 2 if that suites your needs. You probably want the least amount of frictions for your users in terms of not updating .NET. Windows 7 comes with .NET 3.5, Vista with .NET 3 (similarly for the server OSes).
If you know you're targeting Win7 users and above then .NET 3.5 is fine. As the other posters mentioned, the main benefits of .NET 3.5 vs 2.0 is really
LINQ
WPF
WCF
If you are a #2 scenario above, then by all means, use .NET 4. There are many improvements including LINQ, but also in the runtime and if you control the systems then it's definitely worthwhile to be 6 years in the future from a software perspective. Even more so for #3.
For #4, you'll have to decide whether that's an issue for your clients. Most the time it's not, but it can be.
Of course, you can use VS 2010's Multi-Targeting feature to use modern tools regardless.
Not too long ago I wrote the client part of http://chatpast.com which has to be installed. As painful as it was, I wrote that in Windows Forms and .NET 2.0 because that was the least likely to cause problems for users and require a .NET install / upgrade. But the server-side code is all .NET 4.0.
So I guess you can even say that it's not purely and either/or choice. Think about what makes sense for each part of your deployment.
I'm looking to upgrade my ASP.NET web app to the .NET 4 framework. Would I see performance improvements right away?
According to this blog post, there are supposed to be internal runtime improvements that should help out of the box.
According to Microsoft, there have
also been a number of invisible
performance improvements in the
internals of the ASP.NET runtime that
should make ASP.NET 4.0 applications
run more efficiently and use less
resources. These features come without
any change requirements in
applications and are virtually
transparent, except that you get the
benefits by updating to ASP.NET 4.0.
There is a PDC presentation (which I cannot currently find) that claimed the same thing. I would assume that YMMV depending on your implementation, in any case.
Obviously ASP.Net 4.0 will benefit from any areas of the .Net 4.0 runtime on which it depends that are improved. It's usually safe to assume that a new release will make things no worse...
A lot of the performance improvement is probably in development. A lot of things have been improved like handling of ID's so Javascript can interact better with controls. And some C#4.0 features like the dynamic object and it late binding. Here is a list of all the benefits ASP.NET 4.0 Have:
http://www.asp.net/learn/whitepapers/aspnet4
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Why should I upgrade to c# 4.0?
Our projects are currently all C# 3. If we dont have a specific requirement for features that C# 4 provides, would there be any other reasons for us to upgrade? Thanks.
Edit
There seems to be more of an advantage with using the new CLR and not just the new language features.
I personally don't feel that there are great language enhancements between C#3 and C#4 if you're targeting the same framework (2.0-3.5).
However, if you move to .NET 4 CLR as well, I think there are all sorts of benefits in the runtime you can take advantage of. My favorite feature is the parallel task library.
It depends on what you want to do. I don't there are killer language features that 2.0 (Generics) and 3.0 (LINQ and Lambdas) had. C# 4 is more scenario based (see list below for some). If you want to:
take advantage of the new features in WCF (default endpoints, improved WCF REST support, etc.);
work with Entity Framework 4 and it's new features along with WCF Data Services to expose your EF model as a data service;
take advantage of some of the multi-threaded enhancements (e.g. Tasks instead of using Threads);
CodedUI tests (more of an IDE thing, not a language thing);
etc.
...then maybe I would. (Most of my projects utilize WCF in some way, so I'm in the process of upgrading.)
I wouldn't upgrade just to upgrade. Upgrade if you have a business/technical reason to do so. You have to weigh the costs (less time coding while you upgrade your environment) with the benefits (latest language, and as one commenter said, happier developers).
Plus, the IDE is nice (although I've found it a little unstable at times). And as w69rdy's comment said, it's backwards compatible. You may want to give the IDE a try and still stay on .NET 3.5 just to try some of its features (like the extension manager and schema comparer).
If your software is fairly static and business critical then an upgrade may present a risk to the production uptime of the business. However, if you plan to continue development of the business' software well into the future then at least planning to upgrade is a step in the right direction. There's no reason to limit one's development to older versions if the company wants its code to keep moving forward. Future problems may have easier and more expressive solutions using newer language capabilities.
There's also certainly something to be said about keeping one's development staff current on technologies. If the business wants its technologies to remain static, it's going to have an increasingly difficult time finding talent over the years.
If upgrading to C# 4 is not a vey large pain for your system, then it's worth it just to have you projects on the new runtime, if .NET 4 were running on .NET 2 like .NET 3.5 is I would say don't bother, but the benefits of being on the newer runtime are futuresafety in this case since there will be future .NET releases based on the .NET 4 runtime, and the upgrade may be more difficult come that time.
I am making the assumption that you're asking if it's worth it when you don't need it because it wouldn't be extremely difficult for you to upgrade, if it would present particular risk and difficulty in your project then it would not be advisable without a sufficient business need for the functionality in .NET 4
If you are using ASP.NET WebForms it might be worth. Take a look at this blog entry.
Web.config files are much cleaner now and css support was enhanced a lot. WebForms Routing is also a core feature under 4.0. Best of all, you finally get full control over your control id's!
In my opinion, WebForms still isn't as nice as ASP.NET MVC, but it got much required love in 4.0.
Our one and only enterprise application suite has been developed over last 3 years using C# 2.0 on .Net 3.0. We use winforms and WCF heavily. The development tools is VS 2005 Pro / TFS 2005 / Resharper 3.1
As technical lead I obviously understand the benefits in a move to C#3.0 and .Net 3.5. But I want to convince management for a move to C#3.0, .Net 3.5, VS 2008 and TFS 2008. They will obviously be interested in things like productivity, cost, quality etc. Please suggest me some ideas on how best to make my case.
Given that this may not happen till mid next year am I better off to hold till VS 2010 and .Net 4.0 is out.
"If we don't upgrade to newer technologies, it will be more difficult to hire good developers, and those who we already have will be fleeing soon... probably including myself..."
Is there much in .NET 4.0 which will benefit you? C# 4 itself doesn't have many new features... whereas I'd expect you could make good use of the C# 3 features. .NET 4.0 does have some very cool things (in particular Code Contracts and Parallel Extensions) but you should really look at what you would use.
If management is nervous about changing framework version, you could upgrade to VS2008 and use C# 3 but still target .NET 2.0. (Most of the C# 3 features still work when targeting .NET 2.0.) Using LINQBridge you could even still use LINQ to Objects, which is hugely beneficial IMO.
Of course if you can upgrade to .NET 3.5, you'll clearly get more opportunities for LINQ goodness, etc.
Whip out the Microsoft expiration schedule on technologies, figure out how long your current solution set will be supported.
Look to things like Linq-to-Entities. If you don't currently have an ORM, this is a huge time saver.
It's always easier to upgrade version by version than it is to jump several versions. I learned this over time. Step by step upgrades were almost always painless. Upgrades that jumped multiple versions required a signficantly larger amount of extra code and testing.
Identify the top 5 features in your "nice to have list". How many of them are only provided by, or provided in a better way, by the new version?
Don't push for bleeding edge. There's a cost to being on the very edge of emerging technology. That cost is often very hard to justify from a business standpoint.
You have change code anyways. Figure up the cost of the next X feature changes. Try to roll it into a release. "We can do it as part of XYZ release with only NN extra hours, saving MM hours over the next six months".
Look around the web for stats on code rollover. Most custom systems are "rewritten" gradually over time as the business process changes. However management tends to view software as a "write once, use forever" endeavor with only some maintenance costs. Make sure they understand that this is them taking control of the upgrade process, and them guiding the future of their tool in a planned fashion, as opposed to just whatever comes out after dozens of minor changes.
Edit: This all assumes that there actually is a cost justification, which you will hopefully answer for yourself while going down this list.
I don't think any productivity gained by going from C# 2.0 to C# 3.0 can be easily justified for a particular project. Rather than try to justify moving to the new version of the language, think about why you wouldn't?
Does the group want to stay with VS2005 forever, or are they planning on moving to VS2008 some day. If they want to stay at VS2005, consider the fact that that compiler is now on extended support, pretty soon it won't be supported at all, and you won't be able to get even security updates, similar to VC6. Furthermore, the new version of Microsoft's SDL (5.0) requires the use VS2008 or later.
If the group is willing to move to VS2008 eventually, then determine if you can work in a mixed mode environment. This can work effectively if you have a large code base, so new components are built with the newer tools.
Once the team / project has moved to VS2008, then using C# 3.0 features as opposed to sticking to the C# 2.0 subset shouldn't really be an issue.
For VSTS, the best thing to do is to try to use it on a new project.
You will have to upgrade from C# 2.0 to get LINQ. This technology is very powerful, not only for querying databases, but for development in general.
Upgrading should (at least in theory) be easy. You recompile and pay attention to warnings about obsoleted calls.
The biggest problems I've ever run into when trying to upgrade an enterprise application and convincing management was because of the deployment cost. When you upgrade to .NET 3.5, all your clients will have to get the 3.5 framework. Depending on your end user audience, this could be a big deal. That was the holding factor for management whenever we tried to pitch it. The language features, framework features, and other benefits/costs really didn't matter much to them. The deployment cost kept ringing in their ears. If you can make the deployment cost minimal (i.e. you might roll the 3.5 framework into the next install or something), then you'll probably be able to show that the productivity benefits far outweight the costs. Otherwise you might find yourself in the situation I found myself in.