-
Notifications
You must be signed in to change notification settings - Fork 649
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
Support patching a single given CommonAssemblyInfo.cs #224
Comments
I think this is a good idea. I don't think this is a weird setup at all. While I don't personally use this approach, I have seen it used a lot. If we are allowing a file path to be passed to /UpdateAssemblyInfo should we allow multiple file paths? Should it be a fully qualified path, relative to the working directory or a pattern to search for? |
See, this is what I love about discussing those things - it raises all those wonderful questions, which in turn, can be turned into test cases :) This is TDD :D I think for making this easy, initially, it could be made to support just the one file. I think many people have exactly this scenario - one file which is linked to all projects. This is common in centralized environments, like SVN and TFS, where the last revision is being asked from the source control, and appended to the version. I think this can be easily made to support both relative and absolute paths, so... both :) |
Also, it seems that |
#magicfeatures All sounds good to me mate :) makes sense to start with one file. Note: if there is a change to command line args then this will need a change: JetBrains/meta-runner-power-pack#32 |
I'll handle it. I already added some tests to correctly handle |
If my pr hasn't been merged you might need to submit a pr to my pr (unless you pros the jet brains guys to merge my pr - it's been sitting there a while |
Yeah, I like this addition. We have an existing code base that would be in the same position. Going forward, I think I would just use the update flag to go through and find all the AssemblyInfo files in the solution folder, rather than using the Common one, but for existing project, this would really help! 👍 |
We should fix that.. i noticed that a while back. Keep forgetting to fix |
@hmemcpy Do you know when this PR will be accepted and released? I'm looking to adopt GitVersion, but I'm not looking to undo my |
Surely there is nothing to stop you adopting it currently though, you just won't be able to automatically update your CommonAssemblyInfo.cs file, instead you will take the output from GitVersion, and pass that into the current method you have to update it, no? |
Sure. I can modify my build script to do what you say, but when there is a PR sitting here that does what I need... I need to know when this is slated to be released so I can make a decision of the path to go down. |
Hi! As far as this PR goes, the functionality is there, it is only missing the console documentation for the switch (it wasn't documented before). For work, I just use the binary produced by my fork, and it works great for us... |
I will sort out tomorrow and do a new release |
Done There is an outstanding related issue #237 - if anyone wants to pick up that would be great :) |
Thanks @JakeGinnivan! |
We have a weird setup (just migrated from TFS), where there's one
CommonAssemblyInfo.cs
file, that contains the version (and copyright) info, and it's linked to all the projects in the solution.It would be great if
/updateassemblyinfo
could take a filename parameter, to update just the given file. This would work great in our current setup, without recursively updating all AssemblyInfo.cs files.I'm planning to implement this in GitVersion, I'll send a pull request :)
The text was updated successfully, but these errors were encountered: