This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
I am getting the following error code on my TFSBuild machine when trying to build my solution. This builds fine in my development environment but when the nightly build runs on the TFSBuild server, I get this error...
error MC3074: The tag 'RowToDescriptionConverter' does not exist in XML namespace 'http://namespaces.mindscape.co.nz/wpf'
Does anyone have any idea why this happens? I am using VS2010 Ultimate but Visual Studio is not installed on the server. WPF Elements (WpfElements3Professional.msi) is installed on the server. I am not using a nightly build but just using the WPF Elements 3.0 release.
Thanks, Vernon
|
|
|
|
|
It looks like this *might* be caused by a broken reference, although if that were the case I'd expect you to see a lot more errors. This could occur if your machine is 32-bit and the TFS box is 64-bit. The best solution for reference path issues is to copy referenced DLLs (and the associated .LIC files) from the install directory to a Lib directory within the project structure (and under source control), and reference them at that location rather than at the install location. |
|
|
|
|
Hi Ivan, My development machine is Windows 7 64-bit and the TFS Server is Windows 2003 32-bit so I'm guessing this could be the problem. My reference in my project is to "C:\Program Files (x86)\Mindscape\WPF Elements\Bin" but on the server the installed location is "C:\Program Files\Mindscape\WPF Elements\Bin". Is there any reason why WPF Elements is not installed in the GAC or registered as a .NET Component? I'm just thinking this could possibly make it easier for references. Thanks! |
|
|
|
|
Yep, that sounds like it's probably the problem. Regarding installing in the GAC or Assembly Folders, this relates to the way we prefer to manage external dependencies in our projects. In our own projects*, we always take copies of referenced assemblies and place them in a source-controlled project Lib directory. This means that (a) projects are easily portable from machine to machine (including build servers), because the project comes equipped with all its dependencies, (b) projects can rev independently (if Project A upgrades a DLL from v1 to v2, Project B doesn't suddenly get landed with v2 as well), and (c) we can revert dependencies alongside the rest of the project, for example if we are trying to locate a problem in a particular build. * By "projects" I mean business projects, not Visual Studio projects. Many VS projects may share the same Lib directory if they all get built together. So more like a VS solution or family of closely related solutions. Now if we installed in the GAC, then you'd have to actually run the WPF Elements installer on the build server, which would modify the global state of the build server. With the above "private Lib folder" structure, you never need to run the installer on the build server, because the build server picks up the DLL from source control (and the build server doesn't need all the other stuff the installer provides like samples, help files, etc.). This makes upgrades a bit easier (of course, you have to copy the files to the source-controlled location, but that's on your desktop, not on a locked-down server). We try to keep all our developer libraries xcopy deployable and installing in the GAC runs against that philosophy. We've debated back and forth over registering in Assembly Folders. So far our feeling has been that we don't want to do it because (a) it adds noise (there are already hundreds of assemblies in that dialog, all yelling "me me me!") and (b) if you're referencing a private copy (as we favour) then having it appear in Assembly Folders doesn't help, and in fact makes it more likely that someone will incorrectly reference it at the install location. But we appreciate the feedback on this -- we're not dogmatic about it and will reconsider if that's what customers want. In the meantime, I hope this explains the reasoning and also that it's useful to you in your own project structuring! |
|
|
|
|
Thanks for the explanation. That does make sense. I have created a Lib folder under source control and updated my references. That took care of the problem. Thanks for your help! |
|
|
|
