Skip to content
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

SetAssemblyVersion is too verbose #2661

Open
pchinery opened this issue Feb 24, 2022 · 7 comments
Open

SetAssemblyVersion is too verbose #2661

pchinery opened this issue Feb 24, 2022 · 7 comments

Comments

@pchinery
Copy link
Contributor

Description

Right now, AssemblyInfo.setAssemblyVersion is very verbose, which makes the logs hard to read.

Our build process is like this:

  • Update multiple AssemblyInfo.cs files at the beginning of the build with the current version number (and additionally the current commit ID)
  • Compile
  • Revert the changes to all AssemblyInfo.cs files

As AssemblyInfo.setAssemblyVersion writes one trace message per AssemblyInfo and one more line per attribute that was not changed, this can get really messy. When actually searching a problem, we have to scroll up a lot.

Suggested behavior

To reduce the load, I would suggest to modify the "alright, nothing has changed here" messages and either remove them completely or only show them in verbose mode. This will reduce the number of trace lines instantly.

As a more enhanced solution, it might be desirable to completely disable these trace messages during clean up, but that would probably require changes that will affect of lot of use-cases.

I'm happy to provide a PR, but I wanted to discuss this first. Is this even a good idea? What would be the favored approach?

@yazeedobaid
Copy link
Collaborator

@pchinery I'm not aware of a method called setAssemblyVersion in the FAKE codebase. Could you please direct me to that method?

If I understand correctly, what you are doing through your build process is like how the FAKE build process is set up. We have a target called SetAssemblyInfo in which we update all the AssemblyInfo.cs files for all FAKE modules with the release/build info. The output we got from that target is as follows (output is shown for one module - project):

Starting target 'SetAssemblyInfo'
.> "C:\Program Files\Git\cmd\git.exe" update-index --skip-worktree C:\Code\ExternalLibraries\FAKE\src\app\fake-cli/AssemblyInfo.fs (In: false, Out: false, Err
: false)
//...

Thanks

@pchinery
Copy link
Contributor Author

Sorry, I had copied the name of an internal helper method, I meant AssemblyInfoFile.updateAttributes

If I understand your snippet right, that's the "next step", meaning after all AssemblyInfo files were updated, they are added to the git index. What I meant is the actual process (and its output) of updating the AssemblyInfo.cs files

@yazeedobaid
Copy link
Collaborator

So updateAttibutes has only one trace statement. Which as you pointed out is displayed always regardless of verbosity level. However, I'm not seeing any trace message with the text "alright, nothing has changed here"

@pchinery
Copy link
Contributor Author

I did not mean it as a direct quote, that's the line:

https://github.com/fsprojects/FAKE/blob/release/next/src/app/Fake.DotNet.AssemblyInfoFile/AssemblyInfoFile.fs#L447

That's triggered for each attribute in each file that is being updated and it completely clutters our build output (especially on the final target where we revert the temporary changes).

For now, we are detaching the Console during the revert, but that's not really a good solution

@yazeedobaid
Copy link
Collaborator

Ok, I see now. Sorry for all the trouble until I understand what is the issue! But yes if the output is cluttering the build we can condition the trace messages to verbose mode only. Please feel free to provide a PR for it.

Thanks

@pchinery
Copy link
Contributor Author

Thanks, I will try to spend some time on that during the next days and will open a PR when I have something to show/discuss

@Thorium
Copy link
Member

Thorium commented Sep 1, 2024

Assembly resolver improved with latest 6.1.1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants