I was previously using OctoPack v3.0.43 and v3.0.42 from Nuget for two projects in my solution.
I just migrated both of them to v3.0.50, and then got an error from my next Teamcity build:
[OctoPack] Using package version: 0.1.0.106681
[OctoPack] CreateOctoPackPackage
[CreateOctoPackPackage] xxx\packages\OctoPack.3.0.50\tools\OctoPack.targets(78, 7): error MSB4064: The “AppendToVersion” parameter is not supported by the “CreateOctoPackPackage” task. Verify the parameter exists on the task, and it is a settable public instance property.
[CreateOctoPackPackage] xxx\packages\OctoPack.3.0.50\tools\OctoPack.targets(75, 5): error MSB4063: The “CreateOctoPackPackage” task could not be initialized with its input parameters.
I figured maybe the Teamcity plugin needed to be updated to work with the latest OctoPack, so I updated it to the latest. Unfortunately I don’t know what version I had previously, but it may have been v2.6.something.
In my Teamcity Visual Studion (sln) build step, in the Octopus Packaging section, I have Run OctoPack checked, and OctoPack package version set to %build.number%, which in this case is using 0.1.0.106681.
How do I fix it so that I can still append a version number to my package?
Thanks for getting in touch and sorry for the trouble you are having. Are you able to do a clean build in TeamCity (to eliminate any existing DLLs) and double check that all projects in the solution use the same (latest) version of OctoPack?
AppendToVersion was introduced recently and is a new parameter that our .targets file passes to a class in a .dll included with OctoPack. Sometimes if a project uses multiple versions of OctoPack, an older DLL will be loaded, and then the .targets does not match the class in the .dll, which causes this problem.
I did a clean build, and confirmed the only version of OctoPack in my packages folder in the TC work directory was .50.
All 3 of my builds were successful.
Corey, can you confirm that no other project uses a different version of OctoPack? If you go to the build directory on the build agent, and look at the packages folder, there should only be one OctoPack subfolder.
Turned out, the solution contained several projects which were still on the old version. On the server build, the old DLL was loaded first (due to the order in which projects were built), so the properties weren’t available, causing the error.
Once I upgraded the nuget package for the other projects (and also removed the old package from TFS), build went fine.
Presumably this could also be addressed by a server build that always downloads the latest nuget package, but I’ve not tested.
We are having the exact same issues on Jenkins build server. We have 100+ projects, and we run different versions of OctoPack in them. Is there anyway to fix this issue, without wiping the project workspace each time?
Thanks for getting in touch! Could you explain a bit more about your situation?
We can’t decide if you have 100+ projects or solutions or a combination of both. Do you have some that need a lesser version of Octopack?
Do all of them build to the same directory?
There is no real issue here we can fix. It is a VS/build limitation and the way they access DLLs. But there are things you can do to make this easier on yourself via process.
Sorry for being unclear. We have 100+ solutions. Each of the solutions contains up to 10 projects. The solutions (and projects within them) can run different versions of OctoPack - as we are not working on all 100 at once. Note: Within a single solution, the OctoPack version will be the same across all projects.
None of them build in the same directory, they all have their own workspace, so i don’t see why the different versions interferer with each other?
And why is it a .DLL problem? All OctoPack does, is modify your .csproj file with some post build events.
The reason it happens is because of MSBuild… when it “executes” the project file, the tasks are performed by loading DLLs and running the code they contain… the octo tasks load the octopack DLL, which provides the code to call pack.exe.
Within .Net, a single DLL (as identified by its internally compiled name) can only be loaded once… so when MSBuild is first executed (usually being told to compile a solution file), it loads the octopack DLL based on the first project to use it… if you have three projects using three versions of octopack, it’ll be whichever version builds first (perhaps a result of build dependency, or a result of manually defining a build order, or by dumb luck / random order)… if other projects in the solution require the older/newer versions, you get the errors that started this thread.
there are a few ways to address this issue:
The easiest is to keep all projects on the same version.
The alternative would be to control which builds use octopack, such that a single build is only ever running octopack once. If the solution only has one octopack project, this is already taken care of.
If your solution contains multiple octopack projects, you have a few steps ahead…
You need to remove octopack from the core projects, and create separate “deployment” projects for each octopack project.within your solution.
You need to create solution files for each octopack deployment. Within each solution, use the configuration manager to only build the deployment project and its dependencies. In doing so, msbuild will be run once per solution (aka octopack deployment); since msbuild won’t execute multiple deployments, it won’t attempt to load multiple/conflicting versions of octopack.
create CI builds for each deployment solution
Personally, I’m a fan of separate deployment projects anyway… it’s been a pattern of Microsoft’s since the days of Visual Studio 3 and InstallShield templates.
The issue in our enviroment was another it seems. Like i tried to explain, all our projects are running with the same OctoPack version. However we have many solutions, and some of them are running older versions of OctoPack. It seems though that the MsBuild process is kept alive in memory (see: http://stackoverflow.com/questions/12174877/visual-studio-2012-rtm-has-msbuild-exe-in-memory-after-close ) . And thus it might conflict with different versions of OctoPack if two or more builds are executed within that “keep alive timespan (15 minutes)”. Adding /nodeReuse:false to the global MsBuild parameters fixed the problem!
