I am interested in being able to turn Glimpse off completely in the lightest weight way that I can manage. Between the glimpse documentat and the response to this question How to disable Glimpse, the difference between turning Glimpse.axd off and defaultRuntimePolicy="Off" the strongest "off" functionality I can see is setting the defaultRuntimePolicy to off in the web.config file.
However, this still loads a number of glimpse assemblies into my process as shown in the debugger - the answer to this question Why is Glimpse still running? sheds some light on why.
So what I've been doing is keeping around a GlimpseOff shelveset that comments out the glimpse configuration in my web.config file and also comments out the references in my .csproj file. And applying it when I really need glimpse turned off. This works, and I'm pretty sure it really does turn everything off fully, but it is pretty cumbersome.
The alternatives I've considered are (a) removing the glimpse nuget pacakges when I need to turn it off, which is even more cumbersome than my current solution or (b) creating a new build configuration in visual studio which doesn't include the glimpse modules and preforms a web.config transform to remove the configuration.
Neither of these seem optimal. Anyone have a better/cleaner/easier way to do this?
You could use an XML transform to remove the Glimpse entries in Release mode/production.
Adding these entries to web.release.config:
<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<configSections>
<section name="glimpse" xdt:Transform="Remove" />
</configSections>
<glimpse xdt:Transform="Remove"/>
<system.web>
<httpModules>
<add name="Glimpse" xdt:Transform="Remove"/>
</httpModules>
<httpHandlers>
<add path="glimpse.axd" xdt:Transform="Remove" />
</httpHandlers>
</system.web>
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
<add name="Glimpse" xdt:Transform="Remove" />
</modules>
<handlers>
<add name="Glimpse" xdt:Transform="Remove" />
</handlers>
</system.webServer>
</configuration>
If you'd like, you can input this transform and your web.config into the Web Config Transform Tester to make sure it works for your app.
Related
We are using MigraDoc/PDFsharp GDI+ which depends on having fonts installed to the system in order to render. We have tried embedding the fonts but the GDI+ version of MigraDoc does not seem to support this.
When trying to move this component to an Azure App Service, it cannot find the fonts. Is there a way to "install" the fonts locally to the App Service so that they would be visible to GDI?
MigraDoc uses PDFsharp to generate PDF files and PDFsharp can use fonts from embedded resources or from files read by the application.
I would use the WPF build of PDFsharp/MigraDoc 1.50 or later and use the IFontResolver interface.
You can use the generic EZFontResolver implementation if that suits your needs:
http://forum.pdfsharp.net/viewtopic.php?f=8&t=3244
A little late to this - but better late than never!
I have found out that this is actually quite easy - and we all know how!
Add a web.config to the WWWROOT of the app service
add the following
You probably don't need to have the < customHeaders > part unless you want CORS
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<directoryBrowse enabled="false" />
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
</customHeaders>
</httpProtocol>
<staticContent>
<mimeMap fileExtension=".eot" mimeType="application/vnd.ms-fontobject" />
<mimeMap fileExtension=".ttf" mimeType="application/octet-stream" />
<mimeMap fileExtension=".svg" mimeType="image/svg+xml" />
<mimeMap fileExtension=".woff" mimeType="application/font-woff" />
<mimeMap fileExtension=".woff2" mimeType="application/font-woff2" />
</staticContent>
</system.webServer>
</configuration>
You can use a Windows Container on App Service for installing custom fonts. Here is how:
https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-windows-containers-custom-fonts
For getting started with Windows Containers on App Service:
https://learn.microsoft.com/en-us/azure/app-service/app-service-web-get-started-windows-container
As I know, Components rely on GDI API may not work on Azure Web APP. We could find this known issue at: https://social.msdn.microsoft.com/Forums/en-US/6ed5c738-390a-4ca7-81d0-370124a4fc88/azure-websites-faq?forum=windowsazurewebsitespreview. At currently, please try to use Azure Web role or Azure VM instead. Please also vote this idea on Azure feedback forum.
I have installed the SlowCheetah extension and Nuget Package into my Console App Project. I have used the context menu to add a UAT build configuration and updated a test setting to check that the value is being transformed.
Unfortunately its not, when I try to Preview the Transform via the Context Menu its just showing me the non transformed App.Config.
What steps can I check to see why this extension is not working?
In the main App Config I have specified an appSetting.
<appSettings>
<add key="TomTestTransform" value="LOCAL" />
</appSettings>
In the App.UAT.config I overwrite it
<appSettings>
<add key="TomTestTransform" value="UAT" />
</appSettings>
When I preview the Transform, or build and check the configuration output, its always using the non transformed version. The setting equals LOCAL.
You need to use xdt: attributes to match and adapt the elements, like so:
<?xml version="1.0" encoding="utf-8" ?>
<!-- For more information on using transformations
see the web.comfig examples at http://go.microsoft.com/fwlink/?LinkId=214134. -->
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<appSettings>
<add key="TomTestTransform"
value="UAT"
xdt:Transform="Replace"
xdt:Locator="Match(key)" />
</appSettings>
</configuration>
With xdt:Locator="Match(key)" you are telling the processor to match the add element based on the key attribute, and apply xdt:Transform="Replace" logic on the whole (located) element.
There is a msdn entry available on possible XML transformations, which is also applicable for SlowCheetah transformations, as they are based on the same "technology".
Additionally, the extension overview has also some good documentation in it!
I've tried everything I can think of and it's definitely configured, but I cant get IIS to work with ColdFusion 10 and default documents.
I'm looking for some help or advice as to what to try, I've added the entries, verified they are in web.config etc., restarted IIS, restarted the web server, and it just won't work.
Where did you place the web.config file? did you place it in the top level directory of your specific application/site?
I do and that works well.
<configuration>
<system.webServer>
<defaultDocument>
<files>
<add value="index.cfm" />
</files>
</defaultDocument>
</system.webServer>
</configuration>
I have a classic asp application inside a .NET 4.0 application. I have set the default document to login.asp, but it does not automatically redirect to it. The entire application functions fine though and even displays the login.asp correctly if I browse to it.
The default document section in web.config is as below:
<defaultDocument>
<files>
<clear />
<add value="login.asp" />
<add value="index.html" />
<add value="default.aspx" />
<add value="Default.htm" />
<add value="Default.asp" />
<add value="index.htm" />
<add value="iisstart.htm" />
</files>
</defaultDocument>
I have looked at other similar questions on this site but were not of much help.
I finally found the issue was because the asp application was assigned to an app pool in classic mode using .NET Framework 4.0.
Once I changed the app pool to use .NET Framework 2.0 (with managed pipeline in classic mode), the default document started to work too!
Make sure you have Read/Write Feature Delegation enabled for Default Document:
DefaultDocument does not redirect to the file (i.e. URL is not changed). It acts similar to Server.Transfer function — executes the file when root URL (http://sitename/) is requested. Probably, your login.asp executed but it has instructions to redirect logged-in users to a different page, or display the different content to them.
Make sure the response is not cached. Clear cache and cookies and try again.
I had this problem today with a brand new asp.net site deployed to Azure. I tried messing with IIS and my web.config included
<defaultDocument enabled="true">
<files>
<clear />
<add value="Index.html" />
</files>
</defaultDocument>
Turns out my problem was that the File > New Project wizard uses .NET 4.5.2 by default, and that isn't fully supported yet in Azure. I recompiled using .NET 4.5 as the target and everything works now!
I'm having an issue with CruiseControl.net where the web dashboard just won't work in IIS. I have tried switching ASP.Net between 64 and 32 bit modes and reinstalling cruise control, but nothing seems to work. Has anyone else had issues with CruiseControl.Net on 64 bit platforms?
Cheers,
Jamie
[Edit]
Thought I should clarify, I am getting a 404 error when I try access the website. I am using the correct address because it asks for authentication. The .aspx handler is working because I don't see the default.aspx page from the ccnet directory.
[Edit2]
I am using the default web.config that comes with ccnet, but here it is:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<!-- Change this if (for example) you want to keep your dashboard config file under source control -->
<add key="DashboardConfigLocation" value="dashboard.config" />
</appSettings>
<system.web>
<httpHandlers>
<!-- Yes, we are overriding .aspx - don't delete this! We are using .aspx since we know it is already bound to ASP.NET. In future we might use a
different extension so that people can add their own ASP.NET pages if they want to, but we should make sure in that case to change how
URLs are created -->
<add verb="*" path="*.aspx" type="ThoughtWorks.CruiseControl.WebDashboard.MVC.ASPNET.HttpHandler,ThoughtWorks.CruiseControl.WebDashboard"/>
<add verb="*" path="*.xml" type="ThoughtWorks.CruiseControl.WebDashboard.MVC.ASPNET.HttpHandler,ThoughtWorks.CruiseControl.WebDashboard"/>
</httpHandlers>
<compilation defaultLanguage="c#" debug="true" />
<customErrors mode="RemoteOnly" />
<authentication mode="Windows" />
<!-- APPLICATION-LEVEL TRACE LOGGING
Application-level tracing enables trace log output for every page within an application.
Set trace enabled="true" to enable application trace logging. If pageOutput="true", the
trace information will be displayed at the bottom of each page. Otherwise, you can view the
application trace log by browsing the "trace.axd" page from your web application
root.
-->
<trace
enabled="false"
requestLimit="10"
pageOutput="true"
traceMode="SortByTime"
localOnly="true"
/>
<sessionState mode="InProc" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;user id=sa;password="
cookieless="false" timeout="20" />
<globalization requestEncoding="utf-8" responseEncoding="utf-8" />
</system.web>
It seems I needed to enable Web Service Extensions for ASP.Net. I'm still not getting an ASP.Net tab in the cruise control website properties, but it is working.
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727> or C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727> for 64 bit
Type aspnet_regiis.exe – i
ASP.NET will register itself and show up in Web Service Extensions
Clarify a bit, does the web-dashboard function incorrectly? Does it not show up at all?
The webdashboard uses Nvelocity, not ASP.NET WebForms, so you have to register a custom HTTPHandler in the Web.config for it to work.
<add verb="*" path="*.aspx" type="ThoughtWorks.CruiseControl.WebDashboard.MVC.ASPNET.HttpHandler,ThoughtWorks.CruiseControl.WebDashboard"/>
Post up your web.config.
Since you just want to know whether it works... it does.
I'm running it on a 64-bit Windows Server 2008 without a problem.
So now we've established it works, perhaps you can describe your issue in more detail?
Could not comment, I wanted to add this to the aswer to Adam:
I had to use this command in CMD for Win2008 x64
"C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\aspnet_regiis.exe" -s "W3SVC/1/ROOT/ccnet"