We have a couple of relatively large Web Forms web application projects, but we are limited on using the .net 4.0 because some of our clients are still using Windows Server 2003, and the .net4.5 is not compatible with that OS.
Would it be somehow possible to make the model binding framework created on the .net4.5 work with the .net4.0 WebForms? Maybe something along the lines of extension methods on .net2.0 (although that is obviously almost 100% compile time stuff) or LinqBridge.
If that was possible to some extent, I think I would take the time to do it. Maybe if the code can be extracted from the original sources (I'm downloading them right now to see how it works) and be plugged like an extension or inheritance of sorts in our current page life cycle.
Does that mechanism have some external dependency that would make this prohibitive?
The WebForms-based feature required changes which are only available in 4.5.
That said, if you require model binding in some form, you could always try using the ASP.NET MVC or WebAPI frameworks for the particular part of your site in which you require model binding, leaving the rest as WebForms. They both currently only require .NET 4.0. And you get the benefit that both of those are supported products.
Related
I'm looking into using ASP.Net Core MVC for some of my new projects. I work on a team of developers for a very large organization, and we each individually write a lot of small web apps. Due to the size of our organization, we have a lot of rules that we have to follow, and sometimes those rules change, completely out of our control. So this is what we have used in the past projects, all running on IIS:
ASP Classic - Each IIS root folder has a shared folder, containing a lot of commonly used .asp files. These files are mostly the same on each server, but can point to different databases for dev/test/prod environments. These library files are used for common things like authentication, authorization, encryption, sending emails, etc... Each application would be in a sibling folder to the shared folder, and include files like "..\shared\library.asp"
ASP.Net / MVC - The closest thing we could find was the GAC. Everybody says not to use the GAC, but for our purposes it does exactly what we need. We built a DLL library, and store it in the GAC of each web server. We then put local configuration (dev/test/prod environment specific stuff) information on the global web.config of each IIS server. Application specific information would be stored in that application's local web.config file.
The beauty of these two systems, is sometimes things change, and we can simply go update the global libraries, and every application that depends on them will adapt to the new code without needing a recompile. We have many applications, running on many web servers. This may not be ideal, but for our needs it works perfectly, considering the rules can change at a moment's notice, and recompiling every application would be a huge ordeal. We just have to be sure not to ever introduce breaking changes into our libraries, which is simple enough. We have zero problems with how it works.
Now, on to ASP.Net Core. Is there an elegant way to do this? It seems like Core doesn't support the GAC, nor does it support web.config. Everything wants to use appsettings.json. Is there a way to create an appsettings.json at the root level of IIS, and have it set global variables like environment="dev", authdatabase="devsql" etc? And can we store a .Net Core/Standard DLL in a shared folder, and have every app load it with a path like "..\shared\library.dll"? The closest thing I could find to do this with .Net framework was the GAC, but I'm not really finding any answers for this with Core. I appreciate any help, thanks!
sometimes things change, and we can simply go update the global libraries, and every application that depends on them will adapt to the new code without needing a recompile
Note that this is exactly one of the reasons why GAC deployment is usually avoided. If you update a dependency, and that happens to contain a breaking change (in any possibly case), then applications will start to break randomly without you having control over that.
Usually, if you update a dependency, you should have to retest every application that depends on that before you deploy the updated application. That is why dependency updates (e.g. via NuGet) are deliberate choices you need to make.
.NET Core avoids this in general by never sharing assemblies between applications and by allowing different versions side-by-side. That way, you can update applications one by one without affecting others.
This is actually a primary reason why .NET Core was made in the first place: The .NET Framework is shipped with Windows, and is a global thing. All applications will always use the same framework version. So whenever Microsoft ships an update to the .NET Framework, they have to be incredibly careful not to break applications. And that is incredibly difficult because countless applications depend on all kinds of things in the framework. Even fixing a possibly obvious bug can break stuff.
With .NET Core and side-by-side dependencies, this is no longer a problem because updates will not automatically break applications that still depend on older versions. It is a developer’s explicit choice to update an application, shipping newer dependencies.
So you should actually embrace this and start to develop your applications independently. If you have common dependencies, consider creating (private) NuGet packages for those, so that applications can depend on them and so that you have a good way to update them properly.
We use NLog or Serilog to do logging. We're busy porting a system from ASP.NET to ASP.NET Core, which has logging built in.
Ideally, we'd like to drop NLog, as there doesn't appear to be a need for it anymore.
However, is the built in logging equivalent to NLog? Is it missing any major features? Is there any point in continuing using NLog (or something similar e.g. Serilog)?
The ASP.NET logging is a common (logging) interface and log implementation.
You could use the common interface and 3rd party library (e.g NLog) together as the infrastructure is prepared for that.
If you take NLog over the built-in logging implementation you win:
changing configuration on-the-fly (while running application without restart)
more targets (e.g. database, file). There is no file target in the built-in: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/logging. The mail target in NLog isn't in .NET Standard yet, but it's planned. The mail target is there for .NET Standard 2 and for .NET Standard 1 there is NLog.MailKit
more options in targets (e.g. file archiving)
writing extra context info, like ${processid}
as we invest a lot of in performance optimization, I would expect performance.
async logging - which isn't in ASP.NET logging as far as I know.
advanced features like buffering, fallbacks & limiting your logs, filter conditions with context info, writing concurrent to one file etc.
NLog is easier to extend (not only targets but also layout renderers, layouts etc.)
possibility for structural logging (Serilog, NLog 4.5)
But as always, if you don't need these features then maybe less (libraries) is more.
I wouldn't say that ASP.NET Core's logging API makes NLog and other providers obsolete. What ASP.NET Core provides is a nice abstraction so logging frameworks can be switched without changing code that depends on logging.
Nlog still provides useful configuration features that are not implemented in ASP.NET Core logging API.
I want to make use of the Reporting Services ReportViewer control in an ASP.NET Core MVC project.
The solution as proposed in other answers it to add a webform to the project.
However since ASP.NET Core doesn't support webforms I cannot add the control to a webform.
Is there any other workaround that might possibly assist me in using the ReportViewer control in an ASP.NET Core Web application?
Update 2019
I have ReportViewer working on ASP.NET Core on Windows, and most features (not PDF and Images/PowerPoint) also work on ASP.NET Core on Linux.
There's still some bugs to weed out, though.
You can learn more about it in this github issue.
I can't release it publicly, because ReportViewer has a rather constricting license...
It is based on the AspNetCore.Reporting nuget by amh1979.
You might try the wrapper nuget around ReportExecution.asmx, also by amh1979, this has no licensing issues, but it's no real ReportViewer.
Original post:
No, you can't.
Microsoft is only just evaluating creating a .NET Core ReportViewer control.
Which means there isn't any at present (05/2017).
There also isn't any ReportViewer "control" for ASP.NET MVC.
There is only alanjuden's wrapper around MS-ReportServer's ReportExecution.asmx.
But that isn't the same. That will still require Windows Authentication on the report server (along with user-must-be-member-of-specific-ad-group), and a SSRS server running on Windows.
If you anyway have an SSRS-ReportServer on Windows, you're much better of embedding SSRS ReportViewer.aspx in an iframe. You might want to add forms-authentication to your reportserver. Also, if it needs to be cross-platform (=cross-browser = non-IE), you need SSRS >= 2016 (cross-browser not available in SSRS 2005/2008R1/2008R2/2012/2014).
If you're on Windows and don't want (your customer) to have to install a specific version of SSRS (which means you have to license a MS-SQL-Server), you can create a .NET non-core web application on IIS (on the same domain), and share the auth-cookie. Then you embed that ReportViewer from the IIS .NET non-core application via iframe (or link with target=_blank) in your .NET Core Web-Application. That way you don't require an SQL-Server license, and no MS-SQL-Server if you, for example, use MySQL/PostgreSQL/Oracle.
Other than wait, you can bundle Apache Tomcat with BIRT into your application, and use Launch4J to redistribute it with the JRE. Then you'll just have to use the Eclipse-BIRT ReportDesigner to create BIRT reports (non-SSRS-reports).
Or you can embed JasperReports with JasperServer.
This would be far more difficult to bin-deploy than BIRT.
But I guess docker to the rescue.
Jasper and BIRT have the advantage that they also run on Linux/Mac.
However, that means you either need the JRE installed on the server, or bin-deploy the JRE along with your application.
Jasper's advantage over BIRT is that it is faster, and that it supports vertical text (not just in the web, and vertical-text is not rendered as image).
There usually are always issues with the BIRT releases downloaded from their website that prevent running BIRT at first. Be that a missing JAVA_HOME environment variable, a missing .jar-dependency or an invalid signature in a .jar file. For information on what it will be on your machine at your time, consult the TOMCAT logfiles, and then google the problem.
The nice thing about BIRT is, that it's comparatively easy to bin-deploy.
Another option would be jsReports, if you like nodeJS.
However, Bin-Deploy that without installation and complications will be even harder (PhantomJS, Webkit, wkHtmlToPdf - for example with an ARM-processor on Raspberry PI).
If you have a few years to spare, you can also just wait until the SSRS team ports to .NET Core - if that happens at all, that is.
Here is a report viewer works on both ASP.NET MVC and ASP.NET Core.
MVC .NET Core Report Viewer
I have successfully set up an API using ASP.NET MVC 4 on IIS6 (I used Phil's tutorial). When testing, we had it as the "Default website" and so there was no conflict with anything else. I am now being asked to set this up within a FOLDER of an existing website (the existing website is in ASP 1.0...and I cannot modify this...so I would some sort of virtual...something?). So basically, if we have https://www.ourcompany.com, they want the API to be available through https://www.ourcompany.com/api/.
Is this even possible? Phil's tutorial talks about setting up a Virtual Application, but I don't have that option in IIS (and if I had, I'm not knowledgeable enough about IIS to know if that would even allow me to access the API that way). I don't want anything that I set up to mess up the current website either, and there are a couple steps in the tutorial that I'll freely admit I don't fully understand.
If your curious as to WHY, the only advantage (besides being "neat") is so that the same SSL Cert can be used.
Yes that's definately possible at my work we had a similar setup, IIS6, a .NET 3.5 web, with a .NET 4.0 web nested underneath.
You would just set it up as a virtual directory underneath the parent website, point it to your folder, and ensure the value for the "Execute Permissions" dropdown is "Scripts Only" or above, and the correct .NET framework version selected on the ASP.NET tab.
There may be additional values you may need to over-write in your child web.config file, or, alternatively, wrap the entire parent web config with a "Location" attribute.
Forgot to mention, you may need to add manual script mappings for the child web if it doesn't work by default. (This installs the .NET 4.0 script mappings to a specific web) though again not sure if this is required by default. See: http://msdn.microsoft.com/en-us/library/k6h9cz8h.aspx
One more thing - If you're using REST (or an extension less URL mapping which I believe an MVC 4 web will use) - You'll need to add a "wild card" script mapping, which basically tells IIS to serve requests with no extension with the .NET 4.0 framework - See here However where they're referencing .NET 2.0 folders, you'll obviously want to reference the same files but in the .NET 4.0 folders :)
Thanks
Can VS2012 build a proxy in a PCL project to consume a WCF service for SP2010? We add a reference (old school works everywhere else) but once we make calls, for instance GetListsCollectionAsync(), we get all sorts of errors. When we build the proxy, VS gives a warning:
Service proxy generation failed. Proxy requires type 'System.Xml.Linq.XElement' which is not supported in portable libraries
Has anyone successfully subscribed to a SharePoint WCF using a portable class library? The same stuff works fine in .net 4.5 class libraries and in metro libraries. Only portable ones give us this problem. We have win 7 and win 8 devices in the mix - so PCL would be a really good fit.
Got a conclusion here: We found a work around and the statement that this is a bug in VS2012 PCL projects still stands.
We created our proxy in a metro project and simply copied the reference.cs file over into the PCL project. It was a "what the heck - why not" last attempt of sorts, but it actually works. Even better, the calls are awaitable and come with response objects. Awesome!
Cheers,
Gregor