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.
Related
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'd like to run a local NuGet Gallery to serve dependencies to my build system.
I notice in the web.config it asks for Azure details, but the code seems to suggest you can choose 'FileSystem' as a storage backend.
My questions are:
If I choose 'FileSystem' how do I configure the target folder?
Can I instead point the storage engine at an in-house instance of SQL Server?
I'm trying to avoid using a file system because that's what we are using now with NuGet Server and it's very slow. A couple of the devs like to pack and push every single successful build, so scalability is important.
I hope any answers here will help others, too. For background, here is a great link of setting up your own NuGet Gallery. Sadly, the author has omitted all details pertaining to the actual package storage: https://github.com/NuGet/NuGetGallery/wiki/Hosting-the-NuGet-Gallery-Locally-in-IIS
To configure File System Package Store:
<appSettings>
<add key="Gallery:PackageStoreType" value="FileSystem" />
<add key="Gallery:FileStorageDirectory" value="C:\Path\To\Packages" />
</appSettings>
To point to a different SQL Server:
<connectionStrings>
<add name="NuGetGallery" connectionString="Data Source=SQLSERVERNAME;Initial Catalog=NuGetGallery;Integrated Security=SSPI" providerName="System.Data.SqlClient" />
</connectionStrings>
EDIT: Support SQL Server as Package Store
If you want to store your packages as BLOBs in SQL Server, you'll have to make a couple of changes to the code.
First, create a class named SqlServerFileStorageService and implement IFileStorageService. This interface has several methods. The important ones are GetFile() and SaveFile(). Combining folderName and fileName will create a unique key you can use in your database table.
You can use the same connection string NuGetGallery or add a new one for your data access.
You then add an item to the enum PackageStoreType called SqlServer.
In ContainerBinding.cs add a case for PackageStoreType.SqlServer to bind to your SqlServerFileStorageService.
Now the NuGet Gallery should create a SqlServerFileStorageService and all gets and saves will use your class to store the blob in SQL Server.
BTW: I'm basing this on a cursory look at the code. There may be an extra step or two, but these look like the main areas you'll need to focus on.
Hope that helps.
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'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