The default folder structure when deploying with the new powershell publish tools for none virtual directories are
/data
/LogFiles
/site
/site/appRoot
/site/wwwroot
/site/wwwroot/web.config
/site/locks
/site/deployments
then when deploying a new app into a virtual directory:
the structure becomes
/site/wwwroot/approot
/site/wwwroot/testvirt
/site/wwwroot/testvirt/web.config
is this the intended way to have virtual dirs approots in the wwwroot folder?
Is there any flexibility in the placement of approot. What happens when adding the next virtual application, looking at file structure it woulld overwrite the approot of the first virtual application?
Related information to this can be found : https://github.com/aspnet/dnx/issues/928#issuecomment-171617386
I managed to get 3 virtual apps running side by side by setting the virtual directory settings on azure portal like the following:
Then I deployed my webapp to all 3 for test using commandline in the same way that visual studio is doing it.
"C:\Program Files (x86)\IIS\Microsoft Web Deploy V3\msdeploy.exe" -source:IisApp='C:\Users\pks\AppData\Local\Temp\PublishTemp\appname53' -dest:IisApp='appname/app2',ComputerName='https://appname.scm.azurewebsites.net/msdeploy.axd',UserName='$appname',Password='',IncludeAcls='False',AuthType='Basic' -verb:sync -enableLink:contentLibExtension -retryAttempts:2
and manually copyed over web.config to parent folder as indicated in the github suggesting from #davidfowl.
So currently its not possible directly with visual studio tooling to publish this behavior. It should be posible to get it working with visual studio if only the root and one additional virtual app is needed. If wanting more than that the approots folders will conflict.
I also ran into an error (not sure if it was due to alot of manual web.config copying) that the virtual applications had the httpplatform handler added already and it started throwing 500 errors and the fix was to update web.config
<handlers>
<remove name="httpplatformhandler" />
<add name="httpPlatformHandler" path="*" verb="*" modules="httpPlatformHandler" resourceType="Unspecified"/>
</handlers>
I have been using the Azure web app service virtual application directory. In Azure, the following handler would always be appended in the sub virtual application's web.config, regardless!
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
</handlers>
The trick is the remove the handler "aspNetCore" by adding the following code using the following code:
<handlers>
<remove name="aspNetCore"/>
</handlers>
Related
I'm working on an ASP.NET Framework Web App. I have decided to move my connectionStrings from the default web.config file to an external file, for safety reasons etc.
The web.config and the external file are linked together with the configSource attribute.
This works fine when I'm debugging the app locally. When I try to publish the app however, I get the error message: "The 'Entities-Web.config Connection String' argument cannot be null or empty."
For the external file, I have set Build Action = Content and Copy to Output Directory = Copy always.
This is in my web.config file:
<connectionStrings configSource="ConnectionStrings.config">
</connectionStrings>
This is the ConnectionStrings.config file:
<?xml version="1.0" encoding="utf-8"?>
<connectionStrings>
<add name="Entities" connectionString="somestring" providerName="System.Data.EntityClient" />
</connectionStrings>
What can I do to make the connectionStrings load properly when publishing?
You could refer to similar SO thread and use the steps as below.
1.After publishing your project, select the Configure tab.
2.Uncheck the use this connection string at runtime from all your connection strings.
3.Click Save and try to publish the website again.
I have a Restful API project with .Net Core 1 that has a directory that contains some public files (ex: images). I created a controller that retrieved files by file name, but I think it uses CPU and it had has much delay.
for example:
wwwroot
- refs
- runtimes
+ public
- logo.png
+ subdir
- icon1.png
- icon2.png
I want to access this directory publicly from a url like this
https://MyAPIDomain.com/public/logo.png
https://MyAPIDomain.com/public/subdir/icon1.png
I want to IIS directly handles these files and no need to process with dot net. Also they should be resumable on download and browsers could be able to cache theme. How can I do that?
web.config:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<!--
Configure your application settings in appsettings.json. Learn more at http://go.microsoft.com/fwlink/?LinkId=786380
-->
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="dotnet" arguments=".\MyApp.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false" />
</system.webServer>
</configuration>
ASP.NET Core uses IIS as a reverse-proxy. What this means is that all requests are forwarded to your ASP.NET Core app. Period. There's no way around that. The only way you can get IIS to directly serve a file is to host it in a virtual directory in your IIS site. Then, because that particular path is now handled by IIS, it will not forward to your ASP.NET Core app. However, that means then that your ASP.NET Core app can no longer work with that path. In other words, you can't create a virtual directory like "public" and also serve files separately under wwwroot/public.
That said, the static files middleware runs relatively early in the pipeline and is also pretty lightweight. I honestly doubt you'd see much, if any, performance decline over directly hosting static files in IIS. It's also much easier with the static files middleware to handle things like setting cache headers. I'd suggest you simply leave things as they are.
In my application folder I have virtual application QA. There is a folder "help" which contains html and other static files. QA is using form authentication.
All files in help folder are accessible without authentication (for example, www.mypage.com/QA/help/test.html). I need to change this so that if user acces files in help folder (html files or any other static files) then user is redirecet to login page.
I was googling and the ony thing I have found is that this is something with Static file handling and mapping to asp. I am using IIS 6.
I have tried to add line like this
< add name="StaticHandler" type="System.Web.StaticFileHandler" path="*.html" verb="*" validate="true" />
to my web.config (that is in QA folder), but it doesn't help.
Actually, I do not understand this line and also I am new to web.config file administrating.
I also tried to put all static files from help folder into QA, but it also doesn't help.
Make sure you have added a config file to the directory that contains your static files that you want protected from anonymous users like so (this means you will have a second web.config file in the directory you are trying to protect). Which will deny any anonymous users (that is what the does).
<configuration>
<appSettings/>
<connectionStrings/>
<system.web>
<authorization>
<deny users="?"/>
</authorization>
</system.web>
</configuration>
IIS is serving your static files outside of the ASP.net pipeline. Besides adding the declaration you have added System.Web.StaticFileHandler you need to map the extension in IIS. In order to ensure that your .htm or .html files are passed through ASP.net and therefore authenticated.
In your root web .config file add
<system.web>
<httpHandlers>
<add path="*.html" verb="*" type="System.Web.StaticFileHandler" />
</httpHandlers>
Then you need to perform some operation in IIS. These directions apply to IIS 6.0
Open IIS Manager
Right click on your website and select properties
Click Home Directory -> Configuration (displays application extensions etc). You will need the path from a mapped extension already in use by asp.net. The best way to get this is to find an already mapped asp.net extension in the list like .aspx or.ascx, click Edit and copy the Executable path. The path should end in aspnet_isapi.dll.
Click Add
Paste in the previous executable path and the extension (in your case .html).
Repeat this process for any other file types you want handled by the ASP.net runtime.
For my CMS to work properly it needs to be deployed to a virtual directory underneath the www root so it can access (via reflection) the website to manage (note: CMS = N2CMS). When using Visual Studio 'Publish To Web' all is fine. But when I generate the package via msbuild commandline and publish that version my virtual directory is converted to a virtual application.
I configured my remote server to have a virtual directory '/n2' underneath my IIS web application ('exampleapp') and configured this path in the Package/Publish Web settings (IIS Website/Application name to use on the destination server) within my project in Visual Studio.
To generate the deploy package:
msbuild.exe myproject.csproj /T:Package
This generates the zipped package of my code together with MsDeploy commandline batch files to execute (standard msbuild/msdeploy target).
The generated SetParameters.xml contains the following:
<?xml version="1.0" encoding="utf-8"?>
<parameters>
<setParameter name="IIS Web Application Name" value="exampleapp/n2" />
</parameters>
The generated SourceManifest.xml contains the following
<?xml version="1.0" encoding="utf-8"?>
<sitemanifest>
<IisApp path="C:\...shortened-path...\PackageTmp" managedRuntimeVersion="v4.0" />
<setAcl path="C:\...shortened-path...\PackageTmp" setAclResourceType="Directory" />
<setAcl path="C:\...shortened-path...\PackageTmp" setAclUser="anonymousAuthenticationUser" setAclResourceType="Directory" />
</sitemanifest>
Anybody got a clue why the virtual directory gets converted to virtual application?
In the Microsoft.Web.Publishing.targets file, DeployAsIisApp defaults to true:
<DeployAsIisApp Condition="'$(DeployAsIisApp)'==''">true</DeployAsIisApp>
You should be able to override it to false by adding it to the appropriate PropertyGroup element in the project file or in a .wpp.targets file in the project folder; on editing the project file, see
http://msdn.microsoft.com/en-us/library/ff398069.aspx
I've got success with the following combination of deployment parameters (in csproj) when publish web application project (WAP) to the virtual directory without marking it as IIS application:
<DeployOnBuild>True</DeployOnBuild>
<DeployAsIisApp>False</DeployAsIisApp>
<DeployIisAppPhysicalPath>MyWebSite/MyVirtualDirectory</DeployIisAppPhysicalPath>
I can’t made my .NET 2.0 applications (and services) to load their appname.exe.config files on Windows Server 2003 Standard Edition SP2,
I tried to create manifest like this but it didn’t worked
EDIT:
Appname.config is located in the same dir,
App works without any changes on Windows XP, once we move files or use setup to install it on 2003 it fails to load .config file.
The "working directory" of the executable IS the same as it's path! We didn’t change anything while moving it from XP to 2003
I’ve tried process monitor, it says for operations CreateFile and QueryOpen: name not fount, like this file would not exists, but I assure, it is!
I think it might be something wit manifest files under 200, according to this thred on MS Connect
but I don’t know how to solve the problem.
This might be the solution:
http://blogs.msdn.com/junfeng/archive/2006/08/09/692996.aspx
To workaround the bug, add an assemblyIdentity to the SxS manifest.
<?xml version="1.0" encoding="utf-8"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="1.0.0.0"
name="Foo"
type="win32"
/>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="asInvoker"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
Two things come to mind:
First, is the config file located in the same directory as the executable?
Second, is the "working directory" of the executable the same as it's path? If the working directory isn't correct, then it won't be able to locate the file.
One more thing to do would be to get a copy of sysinternals, specifically the process explorer tool to see what file (and path) it's trying to load.
What do you mean by cannot load? Any exception message .Net throws at you? Or it just dies silently?
Your app should load yourexe.exe.config, i.e., mainform.exe.config, where mainform.exe is your app name.