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>
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.
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>
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.
I've applied SQLCE in a project I've been working.
It works fine in Visual Studio and when I run locally (http://localhost:####) it runs perfectly.
But when I publish it at my remote host I receive the "Yellow Screen of Death" the following error message:
Failed to find or load the registered .Net Framework Data Provider.
My Web.Config and references are OK (As I said it work fine at localhost) there is no need to chenge it.
The sdf file is deployed in the correct path.
What is missing?
I found the answer.
When SQLCE is installed to your project it add some files and folders under the bin directory of your webapp.
The following files and folders must be deployed along with you app in the bin folder.
Microsoft.Data.Entity.CTP.dll
System.Data.SqlServerCe.dll
System.Data.SqlServerCe.Entity.dll
WebActivator.dll
[x86] (folder)
[x86]\sqlcecompact40.dll
[x86]\sqlceer40EN.dll
[x86]\sqlceme40.dll
[x86]\sqlceqp40.dll
[x86]\sqlcese40.dll
[amd64] (folder)
[amd64]\sqlcecompact40.dll
[amd64]\sqlceer40EN.dll
[amd64]\sqlceme40.dll
[amd64]\sqlceqp40.dll
[amd64]\sqlcese40.dll
The files in the root of the bin folder (the first four I mentioned above) were deployed but for some reason the x86 and amd64 folders were not sent.
After I deployed those files the app worked fine in the remote host also.
The problem is because your remote host does not have the provider for SQLCE. If you look at your connection string it is something like this:
<connectionStrings>
<add name="name"
connectionString="Data Source=|DataDirectory|yourDbFileName.sdf"
providerName="System.Data.SqlServerCe.4.0"/>
</connectionStrings>
Please note that SQL CE and its System.Data.SqlServerCe.4.0 provider has been released after .Net 4.0 so it was not included in standard .Net framework 4.0. So SqlServerCe.4.0 provider is Missing
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.