I have integrated Elmah.mvc via Nuget in my mvc application. It is storing logs properly but when i do any changes in web.config or restart the site all the error logs stored are erased. Is there a way to preserve its logs permanently in some location probably inside project folder or somewhere. Pls suggest.
Yes! All you have to do is tell Elmah to record logs in files instead of in memory, like this (in elmah's web.config session):
<errorLog type="Elmah.XmlFileErrorLog, Elmah" logPath="~/App_Data" />
to save in memory it should be:
<errorLog type="Elmah.MemoryErrorLog, Elmah" size="1000"/>
Don't forget to allow write access on "logPath" folder.
Related
So I'm trying to use MiniProfiler (https://github.com/MiniProfiler/dotnet) for WebForms website. What I did is:
install package using nuget
add MiniProfiler initialization in Global.asax.cs (Begin_request and End_request events)
add <%= StackExchange.Profiling.MiniProfiler.RenderIncludes() %> statement
set at web.comfig
And still MiniProfiler doesn't work. Simple troubleshooting shows that (in Chrome dev tools) on that page I expect to see MiniProfiler, I see
http://localhost/mycoolsite/mini-profiler-resources/results 404.0 - Not Found
More info: I use .Net FW 4.5.1, IIS8 and Intergated Mode (app pool)
Any Ideas what may be useful for me?
I've (very!) recently blogged about this, specifically the process of getting MiniProfiler working in a hybrid WebForms/MVC application.
Based on the steps that you've outlined that you carried out, it looks like you're missing (as compared to what I've got):
<%= StackExchange.Profiling.ClientTimingHelper.InitScript %>
That said, even without that line I still see server side timings and the MiniProfiler UI so I suspect that your web.config entry was/is incorrect.
Check to make sure that you've put this in configuration > system.webServer > handlers within your web.config:
<add name="MiniProfiler" path="mini-profiler-resources/*" verb="*" type="System.Web.Routing.UrlRoutingModule" resourceType="Unspecified" preCondition="integratedMode" />
There are a couple of other things that you can check as well:
Does the page that you're viewing live in a sub-folder that has a web.config either in it, or in a folder between it and the one where you added the handlers entry which <clear />s handlers?
Do you have anything else present in your application that could be capturing the request for MiniProfiler resources and returning a 404?
I have two web services, of old school, asmx. Both is in the same sub folder, which have anonymous authentication, in a MVC web application that have windows authentication.
When I browse one of them I get expected result, I can Invoke the service, but when I browse the other I get "HTTP Error 401.2 - Unauthorized You are not authorized to view this page due to invalid authentication headers.".
I then rename the second one and everything works fine. Even if I remove the second asmx file I get Unauthorized, instead of "Resource not found".
I have searched the registry and the file system for references to the file name, but find nothing. I deleted ASP.NET Temporary Files, but that did not help.
Any trouble shooting suggestions?
This was not easy to find, but in inetpub\temp\appPools\ there was a folder named as the application pool. In that folder there is "copy" of parts of the IIS config.
At some point we must have accidentally marked the actual asmx file, instead of the folder when we changed autentication. So it contained a special configuration section for just the file. Like:
<location path="Web/Services/ServiceName.asmx">
<system.webServer>
<security>
<authentication>
<anonymousAuthentication enabled="false" />
</authentication>
</security>
</system.webServer>
</location>
When we removed that section it worked again :)
I am in the process of creating a blog site from scratch using MVC 3.0 and the Entity Framework. I am using a SQL CE .sdf file for the data store. This is stored in the projects App_Data folder. Locally, everything works fine. Not a problem. The .sdf file is read and processed without error. However, after using Web Deploy to publish to a shared hosting provider, I get the following error when trying to view the remote site:-
Access to the database file is not allowed
The connection string I am using in web config is:-
<connectionStrings>
<add name="DataAccess.BlogDbContext" connectionString="Data Source=DansMVCBlog.sdf" providerName="System.Data.SqlServerCe.4.0" />
</connectionStrings>
I have researched the problem and have hit a brick wall. Suggestions have included adding App_Data/DansMVCBlog.sdf to the connection string file path rather than just the file name. This does not work as you are advised the file path is invalid. On the shared hosting control panel, I have set read/write permissions on the App_Data folder to be true. Also, in my Global.asax file, I have disabled
`Database.SetInitializer(new DataInitializer());
Am I making a schoolboy error here? Does anyone have any suggestions? Thanks
Looks like the OP may have solved their problem but in my case, it turned out that the database file had been marked as Read Only by my source control system. Clearing the Read Only flag solved the problem.
You probably need to update your connection string
<connectionStrings>
<add name="DataAccess.BlogDbContext"
connectionString="Data Source=|DataDirectory|DansMVCBlog.sdf"
providerName="System.Data.SqlServerCe.4.0" />
</connectionStrings>
Who knows what the solution to this was. All I can say is I was having problems publishing using web deploy, so I switched to using ftp. After that everything worked just fine.
I have googled for the past 3 hours and found nothing on what to do with respect to the windows azure problem:
You do not have permission to view this directory or page.
I did a git master push to azure and the deployment was successful. I also turned on the failed request tracing but nothing shows up but the above statement.
Any ideas on how to troubleshoot this?
I just tested that if you don't deploy your main node.js file as server.js you will get this error because the web.config is specifically looking for server.js as below:
<handlers>
<add name="iisnode" path="server.js" verb="*" modules="iisnode"/>
</handlers>
To further troubleshot this issue you can access the website over FTP as described here.
AvkashChauhan's answer did lead me in the right direction but I also had to add proper rewriting rules. Here is my complete web.config
<?xml version="1.0"?>
<configuration>
<system.web>
<compilation batch="false" />
</system.web>
<system.webServer>
<handlers>
<add name="iisnode" path="server.js" verb="*" modules="iisnode" />
</handlers>
<rewrite>
<rules>
<rule name="myapp">
<match url="/*" />
<action type="Rewrite" url="server.js" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
I hit this error too. I am using MVC and the reason for the error was that on my layout page I had a call to an action that isn't accessible to anonymous users:
#Html.Action("GetMenu", "Users")
For information, I register a AuthorizeAttribute() global filter in Application_Start and my Login action is decorated with AllowAnonymous:
[HttpPost]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public ActionResult Login(LoginModel model, string returnUrl)
{
My website did work previously on IIS7, but Azure is less forgiving. I fixed the problem by adding a check like this:
#if (User.Identity.IsAuthenticated)
{
#Html.Action("GetMenu", "Users")
}
The azure tools have changed a lot since this question.
I recommend people using the azure-cli. But funny enough I actually don't use it after I have used it once to create a site.
What I use now is just the ability to push (git) directly to a remote that is named azure, and the cli is setting that up for you.
But if you don't want to install the cli you can essentially just add the remote repo (your site) manually, like this:
git remote add azure https://<site-or-appservice-name>.scm.azurewebsites.net/<site-or-appservice-name>.git
As you would with every other git remote.
Not specific to node.js but updating in case it helps others facing this issue for a regular web application. This can also happen if the index.html file is not present or is not found because it is in a sub-directory
I just came across this issue and in my case it was the ipSecurity configuration that was causing the issue. Just hd to go and change the allowUnlisted to true.
<security>
<ipSecurity allowUnlisted="false">
</security>
Simple configuration, in the azure portal go to your
web app ->
All settings ->
application settings,
under default documents add the specific name of your document which you want to view, wait for it to update, then refresh your azure link.
I had the same error message after a git push from a local repository.
Solved it by opening the Azure dashboard:
Web app / App deployment / deployment source
and selecting local git repository as deployment source
You need to move your server.js file to your root app folder.
Lots of answers, but I didn't see one that addressed the "how do I debug this?" question, which wasn't obvious to me as someone who is new to Azure and hadn't yet used Kudu diagnostics.
To see the debugging info you're looking for, just navigate to
mywebsite.scm.azurewebsites.net
when you encounter the "You do not have permission to view this directory or page." error on your own
mywebsite.azurewebsites.net
page. This will get you to the Kudu console and give you easy access to everything currently in your logs.
See also the many answers to the closed-but-popular How to debug "You do not have permission to view this directory or page"? question.
I have cornered this error down to a redirect action call by DotNetOpenAuth(http://www.dotnetopenauth.net/)
Basically I have implemented the example here
http://www.dotnetopenauth.net/developers/code-snippets/programmatic-openid-relying-party/
In my application while running locally I hit this line
return request.RedirectingResponse.AsActionResult();
At this point it completes this action and then the azure dev fabric load balancer crashes.
Here is where it gets strange. If I debug line by line into the redirect action it will not crash.
Has anyone seen anything like this that can give me some direction on a fix?
#dthorpe points out that I should tell you all I have tested this by deploying to the production environment and this does seem to work.
We had same problem. There is no fix I currently know of and application still works fine, while deployed in the cloud.
Yet for the local testing purposes I merely introduced switch (it could be compile-time ifdef DEBUG or configuration switch). Whenever there is attempt to authenticate via the OpenID in local dev fabric, we immediately assume the identity is valid and authenticated by the DotNetOpenAuth. This worked for us and allowed to move the development forward.
I have a fix. It's a slight hack, but it does work and you don't have to fake anything.
Change this:
return request.RedirectingResponse.AsActionResult();
to this:
string location = request.RedirectingResponse.Headers["Location"];
return Redirect(location);
This gets around the issue and allows authentication to proceed. I'll allow someone brighter than myself to give a detailed explanation as to why this is the case.
Hope this helps!
If anyone's looking for a quick fix for this, one option is to turn off Azure diagnostics, if you happen to not be using it. This is added to the web.config when you create your project, just comment out the "add" element as shown and you're done.
<system.diagnostics>
<trace>
<listeners>
<!--<add type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" name="AzureDiagnostics">
<filter type="" />
</add>-->
</listeners>
</trace>
Of course this turns off diagnostics so only do it if you're not using diagnostics!