I am building an on-premise ASP.Net application, and want other parties to be able to extend what I have built without needing to recompile the application. Is there a way that you can add models, data access layers and web api controllers after the web application is compiled and deployed?
Thus far, I have developed a solution where I can manage the actual pages via a special web form and store the page template/css/script in the database.
Related
Why can't we create WebAPI project directly just like "WCF Service Application" template in VS.I want to create separate solution not using MVC or ASP.Net WebForms template. In our project we intend to have service layer on different physical machine hosted by IIS to be consumed by different web applications.
The ASP.NET team is in the process of making their offering more cohesive, an effort they call "One ASP.NET." Under One ASP.NET, MVC, Web Forms, Web API, SignalR, and Entity Framework are all first class citizens. They want to make it easy to create web applications that utilize these technologies without having to give up the others; that is, you can make an MVC project but still use Web Forms; or a Web Forms project can easily add a Web API Project.
Anyway, back to your question: you can't create a Web API project directly (i.e. it's not in the main project template list) anymore because it has been rolled into the the single ASP.NET project type.
They explain,
Starting with Visual Studio 2013, the guessing game about which
project type to choose is over. There is now only one web project type
in Visual Studio.
As you can see from the list of templates, we can choose to start with
a standard Web Forms, MVC, or Web API project type. The other project
types from the old MVC template dialog are still here. The interesting
part is the checkboxes underneath the list of templates. Here, we can
choose to add Web Forms references and folders to an MVC project, or
MVC references and folders to a Web Forms project. This is the gateway
to using more of these features in concert with each other in your
project.
Read the full MSDN blog article about One ASP.NET and the new project types here
You can, however, still create a project (or solution) that contains just the Web API references. Just use the ASP.NET project dialog to choose the Web API project type, and make sure all the other check boxes are unchecked. You'll be able to make your project just for Web API, and then go host it on a dedicated box for your services layer. It's all still there, the UI just looks a little different.
I have several asp.net website projects for various sites.
Currently I want to add REST API's to these projects so I can start developing mobile apps (using HTML5/JavaScript/CSS3 and PhoneGap) that make use of these webservices.
Since WCF is far more powerful than regular asp.net webservices (among others with control over the service and authentication/authorization), I'd love to add these to my existing website project.
I did a Google search but cant find anywhere a step-by-step tutorial how this can be done. And also if there's any functionality I'd possibly loose when adding WCF functionality
I was also thinking of creating a new project specifically for WCF, but think I'd rather add it to an existing website project.
Can anyone help me with this?
Depending on exactly what your needs are and how your current web site is configured, there are two approaches.
If you are using a Web Site Project, then you should create your WCF service in a different application:
1) Create a new ASP.Net Web Application Project.
2) Add a new item to the project and select the type of WCF Service or WCF Data Service.
When you deploy this project, you will deploy it to your web server, but not as part of your web site since configuring the web.config will be a large manual effort.
If you are using a Web Application Project, then you could add the WCF Service directly to your existing project. However, I only recommend this approach if you are Silverlight applets within the web site that rely on the user's authenticated credentials.
WCF can be configured with a lot of bindings and it can be configured to return xml or json(.net 4.0). Try to create a wcf service configured to use basichttpbinding or wsHttpBinding and to format the response as json and use jquery to interact with the wcf service. This article might help you http://www.codeproject.com/KB/aspnet/Cross_Domain_Call.aspx
I'm building an asp.net application that will be deployed on Azure. For the moment, I'm using regular asp.net: I'm building it in VS.
I have a web service that's in an asxm file MyService.asmx with a code behind file MyService.cs that calls a different class library called MyBigClass.cs that does most of the work.
If I want to prepare for a deployment on Azure in a few months and make that web service work in its own web role that I can scale based on usage load, should I put the classes that are in the MyBigClass.cs file into the MyService.cs file? The MyBigClass.cs file contains classes that are used for other parts of the application as well; should I remove these classes and only include the ones used by the web service?
Thanks.
Difficult to give a specific answer, and to be honest - I don't think the answer to this would be Windows-Azure-specific, but rather - this is simply a design best practice question, isn't it?
It comes down to how you will go about maintaining the application, and how you are going to manage versioning, but generally speaking - code that isn't shared does not need to get deployed to both roles, so either move it back with the 'parnet' solution (web app or service), or keep in a separate assembly which you will deploy with only the relevant role.
Code that is shared between the web app and service will exist in a shared assembly which you will deploy into both roles.
So you might end up with the following projects
A web site
An assembly supporting the web site
A Web service Service
An assembly supporting the web service
A shared assembly between the web site and web service
I hope this makes sense
I've made a custom MembershipProvider which uses DependencyResolver from MVC3 to find it's dependencies. It works great for MVC apps, but not for the Web Site Adminstration Tool.
Is there some way that I can hook into the Web Site Adminstration Tool request handling to be able to configure a container before it handles the request?
Membership providers should be interoperable and therefore should work just by plugging into the config file of any provider based app.
Web Site Adminstration tool does exactly this, it runs in it's own web application completely decoupled from your MVC app, and just references your provider.
To make this work you need to ensure all dependencies required for the membership provider are packaged in one assembly and bootstrap your IoC container regardless of the environment it runs in. You can code this in such a way to share MVC initialisation, but not depend on it.
Can some one give me the difference between a SharePoint web part and an ASP.NET web part. I found very little information describing the differences.
Thanks in advance.
MSDN - Choosing Between ASP.NET 2.0 Web Parts and Windows SharePoint Services 3.0 Web Parts
You should create ASP.NET 2.0 Web Parts whenever you can. However, there are a few exceptions where using SharePoint-based Web Parts might offer advantages.. The following table provides a decision matrix to help you choose the best option depending on your business needs.
Create a custom ASP.NET 2.0 Web Part
For most business needs.
To distribute your Web Part to sites
that run ASP.NET 2.0 or SharePoint
sites.
When you want to reuse one or more
Web Parts created for ASP.NET 2.0
sites on SharePoint sites.
To use data or functionality provided
by Windows SharePoint Services 3.0.
For example, you are creating a a Web
Part that works with site or list
data.
Create a SharePoint-based Web Part
When you want to migrate a set of Web
Parts using the SharePoint-based Web
Part infrastructure to Windows
SharePoint Services 3.0.
To create cross page connections.
To create connections between Web
Parts that are outside of a Web Part
zone.
To work with client-side connections
(Web Part Page Services Component).
To use a data-caching infrastructure
that allows caching to the content
database.
As far as i got, SharePoint WebPart overrides ASP.NET WebPart
to to persist its data inside the content database of SharePoint Foundation
you can design for and use an ASP.NET Web Part in SharePoint, but not vice versa.
SPF WebParts supports backward compatibility, cross-page connections, conns between WebParts that are outside of a zone, client-side connections (Web Part Pages Services Component), data caching (incl. to database)
they use differing WebPartManager (e.g. SPWebPartManager) and WebPartZone objects, so you can't easy copy WebParts Pages from ASP.NET to SharePoint, but rather export WebParts
Most of that you find on ...
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.webpartpages.webpart.aspx
http://msdn.microsoft.com/en-us/library/ms415560.aspx