When i request to the page. Why can't debug in configure method in file startup.cs?
Are configure method run only once when application start?
Yes, the Configure method in the Startup class of an ASP.NET Core application executes once at application start-up. It configures the middleware components that control how your app will respond to HTTP requests.
More information on this method can be found here: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/startup?view=aspnetcore-2.1
And here's a nice overview of the ASP.NET Core startup process: https://developer.telerik.com/featured/understanding-asp-net-core-initialization/
Related
I have two service in my project one is Events service and other is Parky service (both are in different sln file and both have their own Controllers). I can only run controllers of one service at a time. Example when I build Parky service, I can't call any of method in Event Controllers.
What changes should I do in Startup.cs of Parky service such that when I run Parky Service, All Event Service's Controller method is callable?
I am using ASP .NET Core (MVC).
I am developing an Web application using WCF. I have added Web Reference in Web Application. I am adding methods in WCF as per my need then updating Web Reference in Web Application and it is updating successfully but can't access the newly added methods of WCF in Web Application.
Please Help me...
Do your new methods exist in the contract interface, and do they have the OperationContract attribute?
When you update the web reference, is it looking at a test service or your newly-modified service?
Are you running the modified service when you update the web reference, or is it that the old version of the service is running under an ASP.NET process (check your taskbar) and that is what you are updating from?
Have you rebuilt the client after updating the web reference (I know, I know, but easily missed)?
Yes I did it.
I just deleted Web Reference from Web Application and then cleaned the solution of WCF and Web Application. After that Build Solution of WCF. Then added WCF Reference through "Add Service Refeence" then Build Solution of Web Application. In this way solved my problem.
I have a MVC3 app that is calling a WCF Service Application. The WCF Service App has its own web.config file (comes when you create the project automatically). In this .config I added an appSetting section with key to retrieve.
When I run the MVC app and it calls the WCF svc and the svc cannot see this appsettings value. If I move the appSettings section over to the MVC web.config the service application sees the value.
I would expect this from a calling application if it were a Winform or client based application calling a DLL but not where I have 2 separate apps where I actually want separate configuration files.
For example, I want to configure unity in my web services to perform dependency injection. I don't want the calling web application to know or have to define these values. The service should have them.
The issue I had was with the Unity configuration in the MVC app. Originally I had been pointing at a class library for my services layer, I swapped this over to use WCF. When I did this I left in the old type registrations which unity resolved and caused it to look at the new WCF project (same namespaces/class names) as a class library instead of using the endpoints that I registered.
Ripped out those specific class registrations leaving just the interfaces and endpoints and it worked like a charm.
I have a solution containing
asp.net project
class library
WCF service class library
WCF service application
I've added a project refference from the asp.net project to the class library project and to the service class library project.
I've published the asp.net application, loaded it to the webserver root. all ok.
Now for the service, I've created a new folder on the root called WCF, and placed the aplication in there.
Is this The way I should deploy the sollution? Are this the steps when you have more than a simple asp.net application?
PS: How do I change that WCF folder to make it an application trough a control panel because I get this:http://surveillancecamera.somee.com/WCF. The reason why I get this is described here:
I would treat the WCF service as a separate entity altogether. Deploy the WCF service and verify it works, then deploy the ASP.Net application.
WCF services have a different set of configuration rules that don't always pair nicely in the same "application root" as your ASP.Net web application. In addition, you may want to use the same WCF service in different applications, and it may not be accessible if it is tightly coupled to this ASP.Net application.
Can anyone tell me the purpose of this HttpModule? It's showing up on my HttpModuleCollection list, but I don't know what's it's for.
System.ServiceModel.Activation.HttpModule
I can't find any documentation on it.
System.ServiceModel.Activation.HttpModule come from because you installed "Microsoft .NET Framework 3.5.1" / "Windows Communication Foundation HTTP Activation" feature. If you don't need the feature you can uninstall it of remove the module from your web.config. The less unused modules you load the more quickly run your web application.
If you install this feature after the installation of .NET 4 framework on your server you can receive problems described in http://blogs.iis.net/webtopics/archive/2010/04/28/system-typeloadexception-for-system-servicemodel-activation-httpmodule-in-asp-net-4.aspx.
In general an HTTP module is called on every request in response to the BeginRequest() and EndRequest() events. As a result, the module runs before and after a request is processed. In the section "How HTTP Modules Work" on http://msdn.microsoft.com/en-us/library/bb398986(v=VS.100).aspx you can read more about HTTP modules.
http://msdn.microsoft.com/en-us/library/ms227673.aspx describes how to create a Custom HTTP Module. Some small custom modules can be really helpful. For example, you can read in How to remove the ".svc" extension in RESTful WCF service? a code example (which originate from the book "RESTful .NET", Chapter 5, page 96) "Removing the .SVC Extension from WCF REST URLs". In http://www.west-wind.com/weblog/posts/570695.aspx you can read how to do the same with respect of "IIS 7 Rewrite Module".
The general information about HTTP module is not a part of your question, but I inserted it to better understanding what Activation.HttpModule do, and what other more useful modules you can use or write yourself.
This module is what allows WCF (Windows Communication Foundation) services to work (starting in .net Framework 3.0).
You can safely ignore it and it shouldn't cause trouble. If you really want to get rid of it, you can remove it from your root web.config file (e.g. in
\Windows\Microsoft.NET\Framework\v4.0.30319\Config\web.config). But I suggest leaving it there just in case you need WCF at some point.
A http module is a .net assembly that is called every time your web application gets a request. This is the standard one that asp.net provides that connects your .net web application code to the IIS web infrastructure.
See here for an explanation.
HTTP Modules
An HTTP module is an assembly that is
called on every request that is made
to your application. HTTP modules are
called as part of the request pipeline
and have access to life-cycle events
throughout the request. HTTP modules
therefore let you examine incoming
requests and take action based on the
request. They also let you examine the
outgoing response and modify it.
In IIS 6.0, the ASP.NET request
pipeline is separate from the Web
server request pipeline. In IIS 7.0,
the ASP.NET request pipeline and the
Web server request pipeline can be
integrated into a common request
pipeline. In IIS 7.0, this is referred
to as Integrated mode. The unified
pipeline has several benefits for
ASP.NET developers. For example, it
lets managed-code modules receive
pipeline notifications for all
requests, even if the requests are not
for ASP.NET resources. However, if you
want, you can run IIS 7.0 in Classic
mode, which emulates ASP.NET running
in IIS 6.0. For more information, see
ASP.NET Application Life Cycle
Overview for IIS 7.0.
ASP.NET HTTP modules are like ISAPI
filters because they are invoked for
all requests. However, they are
written in managed code and are fully
integrated with the life cycle of an
ASP.NET application. You can put
custom module source code in the
App_Code folder of your application,
or you can put compiled custom modules
as assemblies in the Bin folder of an
application.
ASP.NET uses modules to implement
various application features, which
includes forms authentication,
caching, session state, and client
script services. In each case, when
those services are enabled, the module
is called as part of a request and
performs tasks that are outside the
scope of any single page request.
Modules can consume application events
and can raise events that can be
handled in the Global.asax file. For
more information about application
events, see ASP.NET Application Life
Cycle Overview for IIS 5.0 and 6.0 and
ASP.NET Application Life Cycle
Overview for IIS 7.0.