IIS -> Lock .NET Core application DLL file

[radenkozec]

When I try to overwrite .NET Core application DLL file using FTP on production IIS server file is locked and it cannot be overwritten.

To deploy new version I need to stop application in IIS to release lock, then overwrite.
It is not possible to deploy without stopping application.

[Tratcher]

See app_offline.htm: https://docs.asp.net/en/latest/hosting/aspnet-core-module.html#asp-net-core-module-app-offline-htm

[guardrex]

If you end up desiring a PowerShell way of doing it, you can use the IIS Admin cmdlets: https://technet.microsoft.com/en-us/library/ee790599.aspx

Stop-WebAppPool -Name $appPoolName

... deploy ...

Start-WebAppPool -Name $appPoolName

[radenkozec]

Thanks for explanation @Tratcher .
I am not sure if this is on your plans but this worked for previous ASP.NET MVC I think?
Do you plan to implement this feature or not?

@guardrex I cannot do it because it is shared hosting enviroment and don't have permission to stop AppPool

[chuchuva]

Can you make it to 'just work' with msdeploy.exe and Azure? If I understand correctly the web site needs to be restarted to prevent file locking. -enableRule:AppOffline works but the whole website is offline for few minutes which is not a great user experience especially given that we deploy few times per day.

See also http://stackoverflow.com/q/40276582/14131

[Tratcher]

@chuchuva maybe, but all magic comes with a cost. Previous versions of ASP.NET did some complicated shadow copying to work around the file locking problems.

[HarelM]

Magic or not, It worked well. I kinda miss it now after the migration to ASP.NET core...

[JaCraig]

Agreed with @HarelM. We've run into issues with this from our automated deployments to just end user experience. We've gone from deploying about 10 times a day with the old MVC to maybe a daily deployment at night and accepting that the people using the Core app are going to be annoyed when we take it offline. While not a show stopper, it's added friction towards Core adoption.

[cyriltovena]

👍

Not supporting overlapped recycling is a regression.

[deadlydog]

Are there plans to revisit this feature and put it on the road map? It's very inconvenient/unfriendly to require everybody deploying a .Net Core website to manually implement a staging-slot strategy if they want to support zero downtime deployments.

Having this feature would make the transition to .Net Core websites much smoother for many people, and would allow for faster adoption of .Net Core websites.

[ajeckmans]

We would like to know as well. Putting a app_offline.htm inside the applications directory does not work.

[DaleMckeown]

I've only just realised this 'feature' after moving a number of sites over to AspNetCore. I can't believe it's deemed to be acceptable to take your sites offline for a few minutes every time you want to publish!

This is bad enough for me as a leader of a small team - are those practicing continuous integration on a large scale shunning AspNetCore? There is no way they would be able to have their site going offline for minutes every hour to republish!

[davidfowl]

Are you deploying use FTP or xcopying? Or are you using webdeploy?

[DaleMckeown]

I'm publishing via webdeploy to IIS.

[ajeckmans]

We are currently working around this issue by just deleting the web.config first (effectively killing the application), but this is not really an acceptable solution in the long run.

@DaleMckeown ideally with a continuous integration workflow you'd have multiple servers behind a load balancer. You'd then pull one server, update it, put it back en move on to the next. Ofcourse this is not always possible (like in our case), so you'll have to live with a few minutes downtime. In our case the app is back up within 30s, so this is not really an issue.

[davidfowl]

@DaleMckeown

I'm publishing via webdeploy to IIS.

There are a few options that can be used to make deployment using webdeploy work well (it supports renaming locked files and dropping app offline automatically). Is that the case by default @shirhatti ?

@ajeckmans

We are currently working around this issue by just deleting the web.config first (effectively killing the application), but this is not really an acceptable solution in the long run.

Does that mean you're doing xcopy deployment?

[DaleMckeown]

There are a few options that can be used to make deployment using webdeploy work well (it supports renaming locked files and dropping app offline automatically). Is that the case by default @shirhatti ?

Thanks David - sounds better than what I am currently doing (manually stopping the site & app pool in IIS). Can you point to some resources so I can investigate the implications of these approaches?

[davidfowl]

@DaleMckeown some info untilI find the source of truth microsoft/azure-pipelines-tasks#5259 (comment)

[ajeckmans]

@davidfowl We're using webdeploy to deploy to our testserver (which btw never gives us problems), from there we copy the files to our live servers using robocopy

[guardrex]

@ajeckmans

We are currently working around this issue by just deleting the web.config first

When the web.config is removed from the deployment, IIS will serve sensitive files from the deployment. An attacker could simply request files continuously day and night until your 30s window opens up.

@DaleMckeown

Following @ajeckmans advice if you ever want to get into the weeds a bit with a PS approach to do that, you can script the process to drop AppPools one at a time for deployment across a web farm. For an example of how that can be done, see https://github.com/guardrex/aspnetcore-iis-ps-publish ... but just look at that as an experimental example and not a production-quality script. I haven't played with that for a while, but it should (in theory) still work.

[ajeckmans]

@guardrex you're right. We copy an app_offline.htm to the dir first, then we remive the web.config, copy over the application, put back the web.config and remove the app_offline (all with a script ofc). Unfortunately just placing the app_offline file in the websites directory does not break the lock on the dlls. We need to remove the web.config, an action we don't need to do for the older asp.net full apps (like old webforms etc)

[guardrex]

@ajeckmans That shouldn't work. When the web.config file is removed, IIS picks that change up immediately, so it should default requests over to the Static File Module and start serving files. Try it and see if that's what happens ...

1. Add app_offline.htm.
2. Confirm that the site serves app_offline.htm.
3. Pull the web.config out.
4. Request a sensitive file (e.g., http://localhost:<PORT>/<ASSEMBLY_NAME>.deps.json ... substituting the PORT and the ASSEMBLY_NAME).
5. You should get the deps.json file served if your Static File Module is functioning correctly.

I wouldn't trust merely removing module with ...

<configuration> 
 <system.webServer> 
   <modules> 
     <remove name="StaticFileModule" /> 
   </modules> 
 </system.webServer> 
</configuration>

... since other modules would remain and possibly present other attack vectors. Maybe one could remove all of the non-essential modules, but we're getting into uncharted waters with a move like that just to cover a deployment via removal of web.config. That's never been an option under the official guidance, and so it's completely unsupported. I recommend PS scripting, for example, to take the AppPool down, or some other strategy.

[guardrex]

I guess I should add a note of sympathy to that ... it did raise a few eyebrows from a security perspective. When that deployment layout change was made, it was discussed, including putting the file back into wwwroot, see ...

Discussion for: Publish for IIS changes to web.config location (IISIntegration 158)
Head-check on moving web.config back to wwwroot (IISIntegration 164)

[EDIT] Perhaps that's your (unsupported) workaround: Move the web.config back to wwwroot, then go ahead with what ur doing. Still tho ... kind'a scary breaking the app to get it offline like that.

[DaleMckeown]

This leaves me even more confused about what we should be doing in this situation.

What's the current recommendation for publishing AspNetCore sites to IIS via web deploy in a way that can avoid file locks?

[JasonRodman]

I would like to know as well. This is becoming a major roadblock to .net core adoption at my organization.

[shahjay748]

When my .net core web application is running and I am trying to publish a new build, it gives me error that DLLs are in use. So I have to Stop the app pool, then update the DLLs and start the App Pool.

Is there any workaround in .Net Core by which I can publish the new Build/DLLs without stopping the App Pool ?

This is by default supported in .Net framework using shadow copy mechanism. Unfortunately, It's been 2 years since the launch of .Net core and seems like there's still no support for such very basic and required functionality. Is there even any plans to fix this in future ?

Thanks in advance for any help.

[ajeckmans]

@guardrex it is indeed scary to break the app to get IIS (or whatever is holding the lock) to release the dll's, however it is even scarier to not be able to push hotfixes to a product. For the time being breaking the app is the only thing we can do, but we're ofc looking into other more modern approaches to handling this :)

@shahjay748 don't hold your breath. If I were te redo the process here, I'd put the app inside a container and just put up a new container and switch traffic and pull the old version down (or something like that). It seems like the more sane thing to do and seeing as .net core is all about new modern ways, just pushing a new version of the app by simply copying over the new files is considered (and I agree) a bit of an arcane way to do it.
Which ofc doesn't help us who are, for the time being, stuck with old processes :)

[bpetersen1]

What i do (Not sure if it's a proper way of doing it), is upload the site to another directory and switch paths in iis

[jkotalik]

We did some internal investigation on this issue. From what I can tell, ANCM does not hold any files/handles in the deployed application. It seems to be an issue with webdeploy itself, and it flakily fails deployment. I never had it consistently fail to deploy the application after retrying a few times once app_offline was dropped.

[ahdung]

Any news? I really expect this.

[ghost]

Thank you for contacting us. Due to a lack of activity on this discussion issue we're closing it in an effort to keep our backlog clean. If you believe there is a concern related to the ASP.NET Core framework, which hasn't been addressed yet, please file a new issue.

This issue will be locked after 30 more days of inactivity. If you still wish to discuss this subject after then, please create a new issue!

[BrightSoul]

lol @msftbot you're doing more harm than good.

[davidfowl]

Bad @msftbot !

[Tratcher]

Any news? I really expect this.

We'd really appreciate feedback to make sure we are delivering a feature that people want and any bugs that people may hit.

[ScottRFrost]

The shadow copying in IIS has been a beta feature for 4 months now (since preview 3) https://devblogs.microsoft.com/aspnet/asp-net-core-updates-in-net-6-preview-3/#shadow-copying-in-iis

How has feedback / testing been? Any word / commitments on if it'll be included as a (non-experimental) feature in .NET 6 final this fall?

[Tratcher]

How has feedback / testing been? Any word / commitments on if it'll be included as a (non-experimental) feature in .NET 6 final this fall?

There has been almost no feedback on the feature so far. Since we're now at the RC1 deadline we're planning to leave it as experimental for this release in hopes of getting more feedback.

[jgasiorowski]

Hello @jkotalik, I've just used shadow copy feature. I am not sure if I am doing it right. But from first time I was using dotnet core I was trying to set dev environment to work similar to what I've experienced with old asp.net.
Since aspnetcoremodulev2 for IIS I am using in proc hosting which points to root directory of my asp.net core application. And obviously when website was running any try to build website was showing errors about locked files in /bin folder.
Only way to work with that was to use visual studio which is able to stop->deploy->start apppool.

Today I read about that shadowcopy feature and got really excited to try it. I've installed new hosting bundle and tried to run it with application using net core 3.1. I can see in logs that shadow copy kicks in (it created new folder with copy of the whole web project contents). But the problem is that I am still getting the same locking error during build if applicaiton is still running

Am I using it wrong? I couldn't find any end to end example how it should work and what is the expected behaviour. Any advice appreciated :)

[adityamandaleeka]

@HaoK @shirhatti ^

[jgasiorowski]

Hello again. I've spent some more time to check if I am not doing something wrong.
I've tested if behaviour for shadowcopy is the same for:

• published asp net core website
• for website which on iis points to main project directory

And on both configurations bahaviour was the same. It was as follows:

• shadow copy gets created correctly and it's contents is updated on apppool restarts
• when apppool is running I was unable to delete bin folder in my project root
• when apppool is running I was able to delete entire shadowcopy folder
• after deleting shadowcopy folder application was still working and responding on requests (folder at that time was not regenerated

It is not what I would expect. Especially after reading ShadowCopyDoesNotLockFiles test case.
Please correct me if I am wrong but I would expect that IIS would lock files in shadow copy folder and it should watch files path which is configured on iis website. So I should be able to do oposite. Which means I should be able to delete my bin folder and I should not be able to delete shadow copy folder.

Looking forward for your reply :)
Thanks

[HaoK]

@jgasiorowski what versions of asp.net core are you using, and what does your web.config look like for the app after publish?

[jgasiorowski]

@HaoK I was trying that for two versions .net core 3.1 and .net 5
web.config looks like that in publish folder

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <!-- To customize the asp.net core module uncomment and edit the following section. 
  For more info see https://go.microsoft.com/fwlink/?linkid=838655 -->
  <location path="." inheritInChildApplications="false">
    <system.webServer>
      <handlers>
        <remove name="aspNetCore" />
        <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
      </handlers>
      <aspNetCore processPath="dotnet" arguments=".\test1.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess">
        <handlerSettings>
          <handlerSetting name="experimentalEnableShadowCopy" value="true" />
          <handlerSetting name="shadowCopyDirectory" value="../ShadowCopyDirectory/" />
          <!-- Only enable handler logging if you encounter issues-->
          <!-- <handlerSetting name="debugFile" value=".\logs\aspnetcore-debug.log" /> -->
          <!-- <handlerSetting name="debugLevel" value="FILE,TRACE" /> -->
        </handlerSettings>
      </aspNetCore>
    </system.webServer>
  </location>
</configuration>

[HaoK]

@jgasiorowski try turning on the debugFile and level and you should see things like:

[2021-08-18T23:25:45.195Z, PID: 52940] [aspnetcorev2.dll] ASPNET_CORE_GLOBAL_MODULE::OnGlobalConfigurationChange 'MACHINE/WEBROOT/APPHOST/DEFAULT WEB SITE/TESTWEBSITE'
[2021-08-18T23:25:45.205Z, PID: 52940] [aspnetcorev2.dll] Stopping application '/LM/W3SVC/1/ROOT/TestWebsite'
[2021-08-18T23:25:45.206Z, PID: 52940] [aspnetcorev2_inprocess.dll] Stopping file watching.
[2021-08-18T23:25:45.207Z, PID: 52940] [aspnetcorev2_inprocess.dll] Starting copy on shutdown in filewatcher, creating directory.
[2021-08-18T23:25:45.208Z, PID: 52940] [aspnetcorev2_inprocess.dll] Copying new shadow copy directory to C:\ShadowCopyDirectory\2.
[2021-08-18T23:25:45.220Z, PID: 52940] [aspnetcorev2_inprocess.dll] Finished copy on shutdown to C:\ShadowCopyDirectory\2. 13 files copied.

When you say you try to delete the bin directory, have you tried just deleting the test1.dll instead of the entire directory to see if your app dll is still locked?

[Tratcher]

Please test 6.0 as well. I don't know if this feature is intended to work with prior versions.

[jgasiorowski]

@HaoK Full log looks like that

[2021-10-09T19:50:22.921Z, PID: 81680] [aspnetcorev2.dll] Initializing logs for 'C:\Program Files\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll'. Process Id: 81680. File Version: 16.0.21245.0. Description: IIS ASP.NET Core Module V2. Commit: 0621c1748eac08dd516edc950559ab7e8308f214.
[2021-10-09T19:50:22.923Z, PID: 81680] [aspnetcorev2.dll] Copying to shadow copy directory F:\temp\iis\shadowcopy\ShadowCopyDirectory\0.
[2021-10-09T19:50:22.934Z, PID: 81680] [aspnetcorev2.dll] Finished copying 13 files to shadow copy directory F:\temp\iis\shadowcopy\ShadowCopyDirectory\.
[2021-10-09T19:50:22.935Z, PID: 81680] [aspnetcorev2.dll] Resolving hostfxr parameters for application: 'dotnet' arguments: '.\test1.dll' path: 'F:\temp\iis\shadowcopy\ShadowCopyDirectory\0'
[2021-10-09T19:50:22.936Z, PID: 81680] [aspnetcorev2.dll] Known dotnet.exe location: ''
[2021-10-09T19:50:22.937Z, PID: 81680] [aspnetcorev2.dll] Process path 'dotnet.exe' is dotnet, treating application as portable
[2021-10-09T19:50:22.938Z, PID: 81680] [aspnetcorev2.dll] Resolving absolute path to dotnet.exe from 'dotnet.exe'
[2021-10-09T19:50:22.939Z, PID: 81680] [aspnetcorev2.dll] Invoking where.exe to find dotnet.exe
[2021-10-09T19:50:23.339Z, PID: 81680] [aspnetcorev2.dll] where.exe invocation returned: 'C:\Program Files\dotnet\dotnet.exe
C:\Program Files (x86)\dotnet\dotnet.exe
'
[2021-10-09T19:50:23.341Z, PID: 81680] [aspnetcorev2.dll] Current process bitness type detected as isX64=1
[2021-10-09T19:50:23.342Z, PID: 81680] [aspnetcorev2.dll] Processing entry 'C:\Program Files\dotnet\dotnet.exe'
[2021-10-09T19:50:23.343Z, PID: 81680] [aspnetcorev2.dll] Binary type 6
[2021-10-09T19:50:23.344Z, PID: 81680] [aspnetcorev2.dll] Found dotnet.exe via where.exe invocation at 'C:\Program Files\dotnet\dotnet.exe'
[2021-10-09T19:50:23.345Z, PID: 81680] [aspnetcorev2.dll] Resolving absolute path to hostfxr.dll from 'C:\Program Files\dotnet\dotnet.exe'
[2021-10-09T19:50:23.346Z, PID: 81680] [aspnetcorev2.dll] hostfxr.dll located at 'C:\Program Files\dotnet\host\fxr\6.0.0-rc.1.21451.13\hostfxr.dll'
[2021-10-09T19:50:23.347Z, PID: 81680] [aspnetcorev2.dll] Converted argument '.\test1.dll' to 'F:\temp\iis\shadowcopy\ShadowCopyDirectory\0\.\test1.dll'
[2021-10-09T19:50:23.348Z, PID: 81680] [aspnetcorev2.dll] Parsed hostfxr options: dotnet location: 'C:\Program Files\dotnet\dotnet.exe' hostfxr path: 'C:\Program Files\dotnet\host\fxr\6.0.0-rc.1.21451.13\hostfxr.dll' arguments:
[2021-10-09T19:50:23.349Z, PID: 81680] [aspnetcorev2.dll] Argument[0] = 'C:\Program Files\dotnet\dotnet.exe'
[2021-10-09T19:50:23.350Z, PID: 81680] [aspnetcorev2.dll] Argument[1] = 'F:\temp\iis\shadowcopy\ShadowCopyDirectory\0\.\test1.dll'
[2021-10-09T19:50:23.351Z, PID: 81680] [aspnetcorev2.dll] Loading hostfxr from location C:\Program Files\dotnet\host\fxr\6.0.0-rc.1.21451.13\hostfxr.dll
[2021-10-09T19:50:23.410Z, PID: 81680] [aspnetcorev2.dll] Canceling standard stream pipe reader
[2021-10-09T19:50:23.411Z, PID: 81680] [aspnetcorev2.dll] Loading request handler:  'C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\5.0.10\aspnetcorev2_inprocess.dll'
[2021-10-09T19:50:23.413Z, PID: 81680] [aspnetcorev2.dll] Creating handler application
[aspnetcorev2_inprocess.dll] Initializing logs for 'C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\5.0.10\aspnetcorev2_inprocess.dll'. Process Id: 81680.. File Version: 15.0.21236.10. Description: IIS ASP.NET Core Module V2 Request Handler. Commit: b92c9f50f0333ea661785ba849f303cde6a93844.
[aspnetcorev2_inprocess.dll] Waiting for initialization
[aspnetcorev2_inprocess.dll] Starting in-process worker thread
[aspnetcorev2_inprocess.dll] Resolving hostfxr parameters for application: 'dotnet' arguments: '.\test1.dll' path: 'F:\temp\iis\shadowcopy\publish\'
[aspnetcorev2_inprocess.dll] Known dotnet.exe location: 'C:\Program Files\dotnet\dotnet.exe'
[aspnetcorev2_inprocess.dll] Process path 'dotnet.exe' is dotnet, treating application as portable
[aspnetcorev2_inprocess.dll] Resolving absolute path to hostfxr.dll from 'C:\Program Files\dotnet\dotnet.exe'
[aspnetcorev2_inprocess.dll] hostfxr.dll located at 'C:\Program Files\dotnet\host\fxr\6.0.0-rc.1.21451.13\hostfxr.dll'
[aspnetcorev2_inprocess.dll] Converted argument '.\test1.dll' to 'F:\temp\iis\shadowcopy\publish\.\test1.dll'
[aspnetcorev2_inprocess.dll] Parsed hostfxr options: dotnet location: 'C:\Program Files\dotnet\dotnet.exe' hostfxr path: 'C:\Program Files\dotnet\host\fxr\6.0.0-rc.1.21451.13\hostfxr.dll' arguments:
[aspnetcorev2_inprocess.dll] Argument[0] = 'C:\Program Files\dotnet\dotnet.exe'
[aspnetcorev2_inprocess.dll] Argument[1] = 'F:\temp\iis\shadowcopy\publish\.\test1.dll'
[aspnetcorev2_inprocess.dll] Setting environment variable ASPNETCORE_IIS_HTTPAUTH=anonymous;
[aspnetcorev2_inprocess.dll] Setting environment variable ASPNETCORE_IIS_PHYSICAL_PATH=F:\temp\iis\shadowcopy\publish\
[aspnetcorev2_inprocess.dll] Loading hostfxr from location C:\Program Files\dotnet\host\fxr\6.0.0-rc.1.21451.13\hostfxr.dll
[aspnetcorev2_inprocess.dll] Initial Dll directory: '', current directory: 'c:\windows\system32\inetsrv'
[aspnetcorev2_inprocess.dll] Setting dll directory to c:\windows\system32\inetsrv
[aspnetcorev2_inprocess.dll] Setting current directory to F:\temp\iis\shadowcopy\publish\
[aspnetcorev2_inprocess.dll] In-process callbacks set
[aspnetcorev2_inprocess.dll] Event Log: 'Application 'F:\temp\iis\shadowcopy\publish\' started successfully.' 
End Event Log Message.
[aspnetcorev2_inprocess.dll] Starting app_offline monitoring in application 'F:\temp\iis\shadowcopy\publish\'
[aspnetcorev2_inprocess.dll] Adding request. Total Request Count 1
[aspnetcorev2_inprocess.dll] Starting file watcher thread
[aspnetcorev2_inprocess.dll] Removing Request 0
[2021-10-09T19:53:24.258Z, PID: 81680] [aspnetcorev2.dll] ASPNET_CORE_GLOBAL_MODULE::OnGlobalStopListening
[2021-10-09T19:53:24.261Z, PID: 81680] [aspnetcorev2.dll] Stopping application '/LM/W3SVC/21/ROOT'
[aspnetcorev2_inprocess.dll] Stopping CLR
[aspnetcorev2_inprocess.dll] Drained all requests, notifying managed.
[aspnetcorev2_inprocess.dll] Starting shutdown sequence 0
[aspnetcorev2_inprocess.dll] Waiting for 0 requests to drain
[aspnetcorev2_inprocess.dll] Managed application exited with code 0
[aspnetcorev2_inprocess.dll] Clr thread wait ended: clrThreadExited: 1
[aspnetcorev2_inprocess.dll] Event Log: 'Application 'MACHINE/WEBROOT/APPHOST/TESTSHADOW' has shutdown.' 
End Event Log Message.
[aspnetcorev2_inprocess.dll] Canceling standard stream pipe reader
[aspnetcorev2_inprocess.dll] Stopping in-process worker thread
[aspnetcorev2_inprocess.dll] Stopping file watcher thread
[2021-10-09T19:53:25.402Z, PID: 81680] [aspnetcorev2.dll] ASPNET_CORE_GLOBAL_MODULE::Terminate

Stopping file watcher log entry was only generated when I was stopping apppool manually

When you say you try to delete the bin directory

Yes I tried delete whole directory. I checked just now if I can delete only the test1.dll file from published location without luck

Sorry - it is polish Windows instance. Modal says that file is in use by IIS Worker Process

@Tratcher I will try it soon since I don't have sdk for net 6 installed. I've installed only hosting bundle to have iis module available. I will return with the answer. But Based on module code and behaviour it really looks like the wrong path is being locked

[jgasiorowski]

@Tratcher I tried with .net 6 application and behaviour is closer to what is expected from that feature.
Everything works perfectly for published version of the app -> whenever I publish new version shadow copy creates new subfolder and application works from new place.
Unfortunately what I have noticed that this does not work correctly in development time.
I usually was setting IIS website to point to root of website project (folder which contains folders like bin, obj, Controllers). In that case I can still build the application without problems with locked files but unfortunately ShadowCopy does not refresh it's contents with new dlls from bin folder.

I have to say that I am sad that it does not work for .net version lower than 6. My preferred environment is to work with services which communicate with normal domain names instead of localhost:52314 because when I have to run multiple such services configuration and trying to remember which service is listening which port is just pain :)

Is there any chance that this feature will support older versions of .net?

Update: I have checked PR #28357 and I couldn't find any sign of check whether application runs under .net 6 or not. I am very curious if there is any technical issue which prevents that feature from working on older versions or is that just design decision? Sorry for being annoying but I am waiting for development workflow which was available long time ago - so I don't understand why shadowcopy could not work for probably all inprocess hosting (so from .net core 2.2 I believe) but it was implemented and was working awesome for old .net framework applications.
My understanding is that shadow copy is a feature which just wisely manages app resources updates and apppool lifecycle and should not be limitted by .net version.
I will be very thankful for an answer ;)

[Tratcher]

Is there any chance that this feature will support older versions of .net?

As a rule we do not add features to older versions, it risks destabilizing existing apps.

I couldn't find any sign of check whether application runs under .net 6 or not.

I recall a change was required in the underlying runtime to allow us to load dlls from a different location. I'd have to dig into the details to confirm which change that was. However, supporting older versions is a non-goal so debugging them isn't a priority.

[jgasiorowski]

@Tratcher Thanks for the answer. But is that a valid point to raise an issue related with shadow copy not working correctly when working on not published website?

[Tratcher]

I wasn't addressing your un-published scenario, I was talking only about your ask for support in prior versions.

I don't think this was designed with un-published scenarios in mind since they have a significantly different layout and workflow. The Visual Studio flow with IIS Express is specifically designed for un-published apps.

[jgasiorowski]

@Tratcher

I wasn't addressing your un-published scenario, I was talking only about your ask for support in prior versions.

I know, sorry my previous comment wasn't formatted correctly - I meant just a question if that would be valid if I would raise an issue about development-time support for shadow copy.
I understand that it was not designed. But I think iis module is designed for working with development-time projects on iis though: https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/development-time-iis-support?view=aspnetcore-5.0
So it think that could be expected by users to work on both setups.

[joelmandell]

Hi. I just want to say thank you for adding this. This made my life much easier. This feature has been working great for me since its appearance in previews @jkotalik

[ahdung]

@joelmandell Introduced in VS2022?

[ScottRFrost]

@joelmandell Can you details the steps you did to enable it, and how you deploy now that you got it working?

EDIT - Related docs issue - dotnet/AspNetCore.Docs#23733

[ghost]

Thank you for contacting us. Due to a lack of activity on this discussion issue we're closing it in an effort to keep our backlog clean. If you believe there is a concern related to the ASP.NET Core framework, which hasn't been addressed yet, please file a new issue.

This issue will be locked after 30 more days of inactivity. If you still wish to discuss this subject after then, please create a new issue!