We have a ASP.NET Web Api project.
A colleague has removed the Microsoft.AspNET references.
We use IIS web hosting.
I would like to use swagger as api help replacement.
But Swagger or the .NET package Swashbuckle/Swagger comes in the CORE with Microsoft asp.net dependencies.
My colleague said we can not use this swagger.
I would like to know what the real problem is (colleague does not really say...) or what the advantage is of a decoupled web api project with asp.net dependecies?
I mean we host on IIS...
I would like to know what the real problem is (colleague does not
really say...)
Not code but, I think this is the first problem. Try to get your "colleague" to explain "why" it's better. (Not just cool code, but also mem/cpu footprint, team-capability-of-take-over, future path, etc.) Good code is maintainable by any qualified developer, not extremely complex and 'understood by only the one'.
what the advantage is of a decoupled web api project with asp.net
dependecies?
Decoupling is a good thing. First, "if you don't use it, don't reference it". To many projects end up having completely useless coupled libraries. Why? Because the "new project" template had them when the project was first created!
In the specific case of Asp.Net core libraries: The current Asp.Net is old, and a new version is on the way. One that will consolidate the knowledge and techniques of "Asp.Net, MVC, WebAPI, OData, OAuth, etc, etc). https://msdn.microsoft.com/en-us/magazine/dn913182.aspx
This means breaking changes are coming.
Not being coupled to the core libraries that are going to change seems like a good idea. If you want to move to this next version you'll have a lot less problems if you're not relying on 'old Asp.Net' functionality.
My colleague said we can not use this swagger.
I think the better way of saying it is; "We will not use anything that tightly couples us to Asp.Net core libraries again since we're decoupling from it".
Related
I have been working with .NET WEB APIs since long and have learnt NODE APIs a bit.
I love working with Javascript and/or C#.
If I look at .NET WEB API, I really can see that things are already developed and taken care by MICROSOFT.
If I look at NODE APIs, I can (at this stage) understand things are working greatly and growing day by day and may be taken care greatly (but I don't know too much about it).
Now being a software developer(.NET), I can play with .NET WEB APIs as I want as I have pretty much experienced with it. .NET WEB API does almost every thing that I want.
Recently,I came across alasql.js(I think its APIs are written in NODE (not sure)). In order to create an excel , I just have to get the list of objects from .NET WEB API, throw it to client end, at client end I will use single line code and it will generate an excel. (So simple. Same thing is possible in C# .and NET WEB API)...
I know NODE is widely used. but at this stage it seems a different platform to me. I'd like to go on with NODE.
I know its amazing if I could run javascript code onto server with NODE.
I know both are great.
But I'm confused with How and When to use them together, individually?
Is there a custom implementation for ASP.NET Identity 2.0 that does not use Entity Framework? I'm hoping for something that does not use a full blown ORM but something along the lines of Dapper. The reason I'm asking is because I am not using Entity Framework anywhere else in the project so I would like to stay away from it if possible.
I know I could work on my own implementation but I do not have the extra time to spend on that.
Frustration and lack of other options forced me to do it myself. Here is the project page on GitHub: https://github.com/ryanrodemoyer/AltProvidersForAspNetIdentity2. It's a ways off from a tested usable project but it's a starting point.
I have an existing ASP.NET MVC 4 project that already uses ServiceStack for REST services, and I just read all about ServiceStack.Razor and would love to move the entire project onto ServiceStack. Right now there is only one controller and view besides the built-in AccountController, and that controller just returns the view and the view is really just HTML; everything else is HTML/CSS/JS + ServiceStack REST.
The only real legacy constraint here is that this new app still needs to make use of SimpleMembership. At present I'm using a custom auth provider to authenticate against SimpleMembership and I would like to be able to continue to do so.
So, what would be the best recommended path to achieve this end? Can I get what I want by modifying my existing project by removing some references, or should I start fresh with an empty ASP.NET app and move the old stuff into it? Can I have SimpleMembership without introducing dependencies that will step all over ServiceStack.Razor?
If you were to start a new solution using only servicestack then MVC would never be there to get in the way.
I use servicestack.razor and love it. It is a lot simpler than MVC in my opinion. Moving everything to the new solution is pretty much going to be copy and paste since what you have works. I wouldn't hesitate and would make the move sooner than later. In the end you are not gaining anything from MVC. You only gain using servicestack. A big deal for me is self-hosting and eventually moving to mono.
This is a question that will have answers based off opinion so I suspect you will receive a few. I have not personally performed such a migration so this is only opinion but is how I would approach it. However, my recommended approach would be:
Retain the existing application/ Given its current simplicity, creating a new app and moving existing items into it seems unnecessary.
You should be able to use your existing auth solution via SimpleMembership and use ServiceStack.Razor. I would proceed as such however it does depend on what other ServiceStack features you may use which could cause conflict. A ServiceStack expert could comment more on this. Even if that did occur, you would be able to work around it relatively easy. At worst, implementing a simple handler would get around almost all issues from an authentication perspective.
Working with different razor engines is relatively easy to do and you can use/enable/disable existing or new build engines via a few lines of code. See here for an example. This should alleviate any concerns around dependencies of other built in or custom engines.
Consider looking at ASp.Net 4.5.1/VS 2013 (since your project is in early days) as it has enhanced membership support and is moving to a more "less dependent" model of components via the Owin stack Asp.Net 4.5.1 and VS 2013. Katana is a microsoft project that also provides some Owin based authentication components see here and here which you could use now and this would remove a lot of dependencies and enable you to migrate other framework with relative ease. Downside is that Katana/Owin has a little ramp up time/learning curve. Again, given your project is in its formative days I would recommend looking into Katana and the ASP.Net vNext stuff as this will make it easier for you and means you dont have to migrate to the new version once it is released.
Is it possible to develop a Web Part without usage of .NET technologies? I'm looking for possibilities of integration of legacy (for example java) applications into SharePoint.
Any valid way for .Net CLR to call your code will do what you want. However with that said, it is likely to be very low level, very obscure and very difficult to do.
A more straightforward approach to reusing your Java or whatever code was if there was some sort of public cross language interface for you to exploit in your .Net skeleton. The obvious answer is a REST or SOAP wrapper around the Java code but it doesn't have to be that. It could be CORBA or JMS or all sorts of things.
Even if you want to integrate Java apps, the web Part will be coded in .NET.
There are a few ways to accomplish this, all of which involve a .NET web part exposing external data. All of your common integration methods apply including exposing the legacy application through web services or even directly accessing the database - you could use whatever your organization is accustomed to with other integrations.
Another possible option, depending on your SharePoint version is the Business Data Catalog (2007) or Business Connectivity Services (2010). These options, while can be a little bit of a pain to set up (though third party tools are available) do allow for some automatic integration of other applications into SharePoint.
Can existing .net application(in C#) be converted to MonoDroid? or
Can we port an existing .NET web app to Android using MonoDroid?
MonoDroid is intended to allow you to develop applications in C# as opposed to Java; not as a means to drop an existing application into place.
You asked about a web app, but I'm assuming you mean an ASP.NET web app, which wouldn't map to the Android API, and couldn't simply be copied over. Even taking your HTML and dropping it into something like Titanium would still require a lot of JS tweaking to make it work.
I have a feeling you're looking at a re-write. Maybe if you can provide more details (is this an ASP.NET app, etc.), I could give a better answer.
Yes no problem. But it wouldn't be an automatic process, nor a particularly simple one. All the UI elements, persistence stuff and so on (the platform specific parts of your application) will need to be redone. Depending on your app, and how it is written, this may be a major part, or a relatively small one. The more corners that were cut originally, the more it will cost to port over.
In addition to Tom's answer, I would say it has some limitations(link 1 and link 2) . I blogged some other interesting moments here.
Here is a good example of cross-platform mobile application (monoDroid, monoTouch, WP7).