-
-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nested Web.config
files are not treated as Content
for publishing and transforming
#83
Comments
You probably want something like <ItemGroup>
<Content Include="**\Web.config" Exclude="Web.config" />
</ItemGroup> This is one of the advantages of the SDK style project. I would always use a location tag in the root <location path="some/plugin/location/handler.ashx">
<system.web>
<httpRuntime maxRequestLength="1048576" executionTimeout="600" />
</system.web>
<system.webServer>
<security>
<requestFiltering>
<!-- 500MB in bytes, default is 30000000 or approx. 28.6102 Mb-->
<requestLimits maxAllowedContentLength="1073741824" />
</requestFiltering>
</security>
</system.webServer>
</location>
<location path="some/plugin2/location/otherhandler.ashx">
<system.web>
<pages validateRequest="false" />
<httpRuntime requestValidationMode="2.0" executionTimeout="600" />
</system.web>
</location> |
This appears to have done the trick, thanks! Do you know what would be needed to also support transformations on these non-root
Thanks for the advice, but this would not scale well for this particular project. This is a legacy WebForms project with over a thousand pages in a multitude of folders, and we have permission management everywhere. If we concentrated all of them in the main file (or even if it was isolated in a dedicated file linked via Having native support for these nested |
Are you talking about including publish profile transforms for msdeploy, or configuration transforms like debug / release etc? MSBuild.SDK.SystemWeb/src/MSBuild.SDK.SystemWeb/Sdk/MSBuild.SDK.SystemWeb.DefaultItems.props Lines 9 to 24 in add70be
You might be able to something along the lines of <ItemGroup Condition="'$(EnableWebFormsDefaultItems)'=='true'">
<Content Include="**\Web.config" />
<None Include="@(_WebConfigConfigurations->'**\Web.%(Identity).config')">
<DependentUpon>%(RelativeDir)\Web.config</DependentUpon>
</None>
<Content Include="**\Web.*.config" Exclude="@(None)" />
</ItemGroup>
Fair enough. As I said - it should work - but I've had issues with this approach in non-sdk projects, let alone with the hacks the SDK does. If you get it to work for you, all the better.
You might need to adjust the line to be something like |
I was referring to the normal transforms, using Perhaps your suggestions above could help someone implementing it directly in the SDK. Your initial suggestion unblocked me to get our publish pipeline going, but I added it to our project with a note in hopes that this is implemented as part of the SDK in the future and we can then remove the customization: <ItemGroup>
<!--
HACK:
Adds all nested `web.config` files manually. Ideally, this should be handled by the SDK, but it only
considers the root `web.config` file at the moment.
More information here:
- https://github.com/CZEMacLeod/MSBuild.SDK.SystemWeb/issues/83
-->
<Content Include="**\Web.config" Exclude="Web.config" />
</ItemGroup> Thankfully we've only had to add this to a single project thus far out of the 8 projects we have currently using this SDK. |
As I switch our old WebForms projects to leverage publishing, I noticed that only the root
web.config
files are properly considered for deployment, transformed and copied on publish, whileweb.config
files inside of other folders in the project (used usually for settingLocation
-based permissions) are completely ignored.I believe it should be possible to treat these nested
web.config
files the same way as the root one so that they properly participate in the publishing pipeline.I've not yet worked around this issue, so suggestions on how to do so besides manually marking each individual file as
Content
in Visual Studio are welcome.The text was updated successfully, but these errors were encountered: