I have an initial build stage with two steps in it. The first is AssemblyInfo Updater, followed by an MSBuild of the source. The next build step simply does a lot of file copies, renames, and similar things with the output from the first stage.
In using AssemblyInfo Updater, I’ve had a number of troubles.
Basic info:
Update Only - not checked
Create Backup - checked
Log Each Property - checked
I do these so I can see what’s going on. Also, I do not have cleanup active so I can go into the agent workspaces and see what’s going on after the fact.
1) Specifying the full path to my AssemblyInfo.cs files doesn’t appear to work properly. I had 13 filenames that I specified and only the first one was triggered. I could tell this via the Log Each Property option and in the logs, the only file being “modified” was the first. I am 100% certain the paths were correct because they all followed the same format as the first one. I also matched up the file paths specified in the logs with the files on disk and confirmed the files were not being updated, even though they clearly had the properties specified. Not that it should have mattered if they weren’t found because according to the “Update Only” setting being unchecked, it should have at least added it to the files and made a duplicate copy of the property.
Eventually, I specified **AssemblyInfo.cs and it “worked”… sort of. I believe there’s a bug in there somewhere because I couldn’t specify individual files to be updated. If I did, it only accepted the first one and ignored the rest. The documentation says you can specify one on each line but it looks like the rest are ignored.
2) The second issue I ran into was that even though there’s a .bak file being created in all of the Properties directories, none of the AssemblyInfo.cs files are being updated, which is bizarre. It made me thing that something wasn’t working properly and I spent a long time trying to figure out what was going on. Eventually, after checking the output, I saw that the compiled dll’s and .exe’s do in fact have the proper settings I specified in the “AssemblyInfo Updater” action. But it bugs me that I’m seeing these .bak files appear in the Properties directories, as though a change has been made to the AssemblyInfo.cs files, but those files are not changed. How is this being passed through?
One thought I had initially was that I had a copyright symbol in some of the Assembly properties and maybe that was messing something up. But even after removing all of those from the source code, this weird behavior didn’t go away. And even if it did fix the files on disk issue, it doesn’t explain how MSBuild is able to take those unmodified AssemblyInfo.cs files and magically turn them into the right ones during the MSBuild step. Any idea what’s going on and why those files aren’t being modified on disk?
The output is technically correct however the bugs I encountered are:
a) You can’t specify more than one individual file in the AssemblyInfo Updater step. I tested this by specifying two AssemblyInfo.cs files, one on each line. The first is updated on disk and has a backup. The second is not updated, nor does it have a backup. If I swap the order, then the first one is updated, and the second one is not so I’m sure I didn’t just mistype something. According to the comments on the page, it’s one file per line so it’s not as though I’m missing a delimiter on my end.
b) When using a wildcard, the files on disk aren’t actually updated. The odd thing is that .bak files appear all over the place as if the AssemblyInfo.cs files were updated. The resulting build does have the correct settings for all of the files, but it’s not reflected in the source code it’s built from, so I’m not sure how this is happening.
Thoughts?
Hi Mike
We’ll check these issues out on Monday. I am wondering if you have a second stage which is also getting the source? If so then the modified files would be overwritten, which might account for the files appearing to be unmodified.
I do have a second stage, but it only ever refers to a second repository (different set of files) in the actions that execute. I checked the Repository Rules and noticed that it did appear to be copying everything from the Source directory from the server back to the agent directory. In that stage, I eliminated the line that read:
$Source$ > Source
and the issue largely went away. Most of the AssemblyInfo.cs files are correct at the end of it all, but I’m still seeing some (that were hit in stage 1 using the **AssemblyInfo.cs) where AssemblyFileVersion was updated, but not the AssemblyVersion.
I think that the issue is that the Source files were indeed being overwritten by the second stage. However that being the case, it doesn’t explain why in the agent directories, specifying a single AssemblyInfo.cs file would not be overwritten, nor would it explain why some of the AssemblyVersion properties would change, but not others.
I believe my initial understanding of it was a bit off, but there still appears to be something wrong. And if it wasn’t clear, this is all running on the same system. What I hadn’t realized initially was that the Source data is copied to the agent by default between each stage. I get how that works now so that was an error on my part. Even with that, there are still unexplained issues.
Monday works. I can work through this with you to answer questions as well if need be. I have it working “well enough” that I can get by and I’m not being blocked by anything.
Hi Mike, thank you for reporting this.
We have identified an issue related to the registration of artifacts (some files from subsequent stages did not register correctly). We have implemented a fix for this which will be available in the next release. This should resolve your items 1 and 2 from the original post.
As mentioned above (by default as specified within the repository rules tab) all source will be exported the agent from the repo cache. If you have modified ‘in place’ (within the source directory) then those changes will not persist between stages. I believe the best way around this (which it appears you have done) is to remove the repository rule and add a workspace rule eg ‘/Source** > /’ . Enable the option ‘log workspace files copied’ if you have not already to see this in action.
It would be great if you could please send us screenshots of your stage options (all the tabs please) and the action in question (support@finalbuilder.com), also an indication of the Continua version you are running.
Thanks again for your support
Actually, I have another for you that might be slightly more devious and it could be related.
When using the AssemblyInfo Updater, if any properties appear in your code which are commented out, then only the first will be modified for each, regardless of whether or not it was commented out. See the following before and after sets of code:
Before:
[code]// [assembly: AssemblyVersion(“1.0.0.0”)][assembly: AssemblyVersion(“0.0.1.0”)][assembly: AssemblyFileVersion(“0.0.1.0”)][/code]
After:
[code]// [assembly: AssemblyVersion(“2.1.0.0”)][assembly: AssemblyVersion(“0.0.1.0”)][assembly: AssemblyFileVersion(“2.1.0.749”)][/code]
I had set the AssemblyVersion to be updated to 2.1.0.0 and AssemblyFileVersion to update to 2.1.0.749. After making the changes you previously suggested to not sync the Source between the agent on the second stage, I noticed this in some of my files. Anywhere that there was a commented out AssemblyVersion line, followed by one that wasn’t commented out, the commented out one was updated, but clearly when it compiles that isn’t going to make a difference.
This explains why my final output didn’t have the right assembly versions that I expected to see. Previously, I couldn’t see the Source directory because it was being overwritten, but now I can. It seems like you might want to ignore lines which are commented out, or at the very least, do a global find/replace instead of just the first property found.
This appears to be the root cause of my problems. I’ve updated my source code to eliminate those commented lines and everything appears to be working properly now.
Looks like it got messed up and I can’t update the post. Let me try reposting.
Before:
[code]// [assembly: AssemblyVersion(“1.0.0.0”)][assembly: AssemblyVersion(“0.0.1.0”)][assembly: AssemblyFileVersion(“0.0.1.0”)] [/code]
After:
[code]// [assembly: AssemblyVersion(“2.1.0.0”)][assembly: AssemblyVersion(“0.0.1.0”)][assembly: AssemblyFileVersion(“2.1.0.749”)] [/code]
bah! Code tags don’t work when you have more than one set:
Before:
// [assembly: AssemblyVersion(“1.0.0.0”)]
[assembly: AssemblyVersion(“0.0.1.0”)]
[assembly: AssemblyFileVersion(“0.0.1.0”)]
After:
// [assembly: AssemblyVersion(“2.1.0.0”)]
[assembly: AssemblyVersion(“0.0.1.0”)]
[assembly: AssemblyFileVersion(“2.1.0.749”)]
Hi Mike
The AssemblyInfo updater action uses regex, so it’s not perfect. There are so many variations on how attributes can be written, so it’s not just a simple search and replace. Short of writing a C# parser (and vb.net etc) it’s impossible to handle every case. We’ll see if we can get it to skip commented lines though, might be possible.
The reason it skips the second AssemblyVersion is because the parser ‘ticks off’ the attributes as it processes them, if there are any left that are not found then it should add them. Its a guard against adding duplicates which would cause the build to fail.
Hi Mike thank you for posting the followup.
I have been able to replicate the situation you are getting. We are in the process changing the default behavior of this the AssemblyInfo Updater action to ignore comments. Ie not update Properties which are contained within a comment (either inline or block style).
We are testing this out now and hope to have it into a release shortly.
Thanks again for your support
No problem. You guys are great. I’ve been a happy FinalBuilder customer for several years and am in the process of migrating over to Continua so there’s a bit of a learning curve, but I like it so far. You guys do a great job.