About the original issue, I'm leaving tomorrow soon in the morning for a meeting, so I'll wait to return in order to analyze it deeper.



It modifies the version when compiling, either before, or after it, and people can choose whether to update the version just in release mode, testing, or both.



You can use whatever template you want, so it doesn't need to be a class file. However, right now, the plugin completely writes the file when updating it, so the file must not have content prone to change. This is the "Smart Update" option I want to soon add, already have the code needed for it (after all, it would be mostly the same code used to read version data from custom templates), just didn't implement it yet.



By default they'd be overwritten, but you can configure the destination filename.



If the XML content is static, you can use your own template, if not, will have to wait for the updated version with the feature.



I know, I've had to do the same in the past.



The plugin supports different versioning styles, one of them is auto-increment, so that could be used as a build counter.

I use AutoVersion 0.9.10118.1209.
But why the "version.as " file is outside of src folder

Simply because not all projects are created that way, and indeed, my team rarely uses a src folder (I know it's a best practice in Flex projects tho).

You can modify where to store the Version.as class file, so it's not a big problem anyway, but will add to my list to check for the Classpaths in order to know where to best store the file.

Added some more questions to the FAQ, updated the project RoadMap, and released v 1.0.10121.1307:

- Correctly initialize some variables like Start Date and IncrementBeforeBuild when a new project is created.
- Added global settings. These are located together with the other FlashDevelop plugins settings.
- Added language detection. Now AS2 and haXe projects will be correctly versioned without having to use custom templates. Also, the default templates aren't embedded inside the assembly, so ayone could make their own default files.
- Added the Smart Update feature. This way you can modify the version data file, and everytime it is update, it will only update the lines corresponding to each version part.

Since there are now more files involved, I've uploaded the plugin as a fdz archive.

I'm analyzing the ExportProject plugin issue and test the Happy Turtle plugin this weekend.

I've already tested Happy Turtle, and it works as expected: just remove its reference to BuildVersionIncrement.dll, add one to AutoVersion.dll, and change the namespace of BaseIncrementor to the one located inside the AutoVersion assembly.

I've uploaded an unofficial, and unsupported binary to Google Code, for all of those that cannot compile it, or don't have the time for it.

But it also don't solve my problem. please add a veriable like" path" and default is "src" .
because many people use the default setting of flashdevelop.

I already said that you can configure where to store the class file.

In the Project Version dialog, modify the Version FileName setting to match your preferred location.



That wouldn't be the proper solution either. The right way of doing it is in my to-do list, once I have some spare time will add it.



Although most, not all project types use that folder structure as default.

Thx

Released AutoVersion 1.1.10139.20:

- Try to get default source path instead of always using the folder where the
project file is located.
- Version file package is auto-detected now.
- Added setting to update the version information of AIR applications.
- Added setting to change AIR descriptor filename.
- Fixed updating of multiple versioning template arguments when Smart Update is enabled.
- Some minor code refactoring.

Is this issue planned to be fixed? I would love to have these two plugins functional.
Anyway I think it would be reasonable to put it in the "Project" menu.

After looking a bit more into the issue, I saw that in order to add some item to the Flash Tools menu, you can do so by using its name, which is always the preferred way instead of using an index, and, indeed, other plugins are doing it that way. I contacted elyon twenty days ago to see if he could test the change, but got no reply so far...



That's what I wanted to do when started to develop the plugin, but the Project menu doesn't have a name, so I couldn't do so without using some dirty method... in order to change some code I'll add a reference to ProjectManager.dll in the following version of AutoVersion, maybe with it I can do this, will have to check it.

And one more thing could you please make it for NET 2.0, like FlashDevelop itself?

Yes, it could be done with no problems, however, I don't consider it to be of high priority, so I've noted it.

I've got no spare time lately because of other projects, so any external submission to the plugin is highly welcome. There is a roadmap for the project in the Wiki section, so anybody can check what could contribute to (although not limited to just that, of course).

I've got some spare time at last again, so worked a bit on AutoVersion.

So far I've added a reference to ProjectManager.dll so I removed some hardcoded data and placed the plugin menu at the bottom of the Project menu, made the plugin target the .NET 2.0 framework, and added localization support, although some text is still missing.

It would be nice if people could test the new version and give some feedback. You can download a pre-release version here.

small question: if i set for example i use something like DeltaBaseYearDayOfYear for one of the variables (say minor), when the year passes, will it auto-incret the major, or it that something that i have to do myself?

i.e.:
Dec 31st: version = "1.365.0.0";
Jan 1st: version = "1.1.0.0"; <- possible? could conflict with an earlier build number
or
Jan 1st: version = "2.1.0.0"; <- desired