In proc host release should publish package named Microsoft.Azure.WebJobs.Script.WebHost.InProc

[aishwaryabh]

Issue describing the changes in this PR

Resolves #10458

Tested in host.official pipeline that artifact is generated:

Pull request checklist

IMPORTANT: Currently, changes must be backported to the in-proc branch to be included in Core Tools and non-Flex deployments.

• Backporting to the in-proc branch is not required
  • Otherwise: Link to backporting PR
• My changes do not require documentation changes
  • Otherwise: Documentation issue linked to PR
• My changes should not be added to the release notes for the next release
  • Otherwise: I've added my notes to release_notes.md
• My changes do not need to be backported to a previous version
  • Otherwise: Backport tracked by issue/PR #issue_or_pr
• My changes do not require diagnostic events changes
  • Otherwise: I have added/updated all related diagnostic events and their documentation (Documentation issue linked to PR)
• I have added all required tests (Unit tests, E2E tests)

Additional information

Additional PR information

[jviau]

Do all the other packages need the same change?

[aishwaryabh]

Do all the other packages need the same change?

@jviau I don't think so, since we want to use the Microsoft.Azure.Webjobs.Script.WebHost package in the in-proc core tools and OOP core tools. We just wanted a way to separate them to cause less confusion. Does that make sense?

[jviau]

Do all the other packages need the same change?

@jviau I don't think so, since we want to use the Microsoft.Azure.Webjobs.Script.WebHost package in the in-proc core tools and OOP core tools. We just wanted a way to separate them to cause less confusion. Does that make sense?

Are transitive dependencies to the other packages involved though? If so, how will those impact this (if at all)?

[aishwaryabh]

Do all the other packages need the same change?

@jviau I don't think so, since we want to use the Microsoft.Azure.Webjobs.Script.WebHost package in the in-proc core tools and OOP core tools. We just wanted a way to separate them to cause less confusion. Does that make sense?

Are transitive dependencies to the other packages involved though? If so, how will those impact this (if at all)?

Synced with Fabio and there aren't any transitive dependencies involved to the other packages since this is specifically for the inproc version of the package and the only other dependencies for the other packages would be WebJobs and other runtime dependencies.

[surgupta-msft]

This may already be considered as part of the process but I believe we also need to inform the release team that the package name is changing for "inproc"? The above changes are not only for coretools but also for the host releases for in-proc.