This repository was archived by the owner on Jan 20, 2022. It is now read-only.
Fixes *.csproj.CopyComplete files from being included in OctoPack packages #104
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
|
fourpastmidnight
force-pushed
the
fixes-CopyComplete-files-from-being-included-in-octopack-packages
branch
2 times, most recently
from
2fda0d9 to
6b2d597
Compare
Back in January, 2018, PR 2878 at dotnet/msbuild was merged. (See https://www.github.com/dotnet/msbuild/pull/2878). There was one simple change, but it unknowingly caused OctoPack to start including extra unnecessary files into OctoPack packages. We found it because we had deployments blow up in Octopus Deploy due to file paths which exceeded MAX_PATH length during deployment, specifically, during config file transformation. The PR had the result of, when copying files marked as CopyLocal, a *.csproj.CopyComplete file is created. It's a marker for the build process so that transitively referenced projects are built appropriately. Near as far as I can tell, because the file is created (via the Touch task) during this target, and subsequently added to the @(FileWrites) item group, and because the path associated with @(CopyUpToDateMarker) item group is an absolute path, the existing exclusion in the OctoPack.targets file is not filtering out these files. So they are being included in the OctoPack deployment packages. While the files are 0-bytes in size and are harmless, they don't belong in the package. They are not a deployable build artifact, and in my case, caused deployment failures. This wasn't caught in changes to OctoPack between Jan. 2018 and Jan. 2019 (the last time any change was made to this repo, and the date of the most recent release) because the unit tests were never appropriately updated to take into account newer versions of Visual Studio, namely Visual Studio 2017 and Visual Studio 2019. This commit updates the unit tests and the OctoPack.targets file so that these useless *.csproj.CopyComplete files are not added to OctoPack deployment packages.
fourpastmidnight
force-pushed
the
fixes-CopyComplete-files-from-being-included-in-octopack-packages
branch
from
6b2d597 to
f364187
Compare
tothegills
approved these changes
Aug 20, 2020
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The organization I currently work for recently had a spate of deployment failures when Octopus Deploy attempted to transform some application configuration files. After a few days' time, we finally determined that this internal Octopus Deploy process was responsible for the deployment failures because it does a directory scan looking for files to transform. One of the file's absolute path in the extracted deployment package location exceeded
MAX_PATHcharacters.The file exceeding the
MAX_PATHlength was a 0-byte text file that is created during builds made with Visual Studio (Build Tools) 2017/2019 as a result of this dotnet/msbuild pull request. This was not caught with the most recent release of OctoPack (v3.6.4 on 14 Jan. 2019) because the unit tests were never updated to use newer versions of the MSBuild build tools.This pull request updates the unit tests to attempt to find newer versions of the MSBuild build tools (it's still hard-coded and will only work up to Visual Studio 2019) and use those first over older build tools. In addition, the
OctoPack.targetsfile was updated to exclude this extraneous file from being packaged by OctoPack.