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 spent a few days tracking this bug down: When creating web deployment packages from one machine, I would see that the Mindscape.Lightspeed.Generator.* assemblies are included in the package while are omitted from packages created from another machine. After lots of digging around, I found that Mindscape.Lightspeed.Generator.* are placed in the GAC, presumably from running the LightSpeed setup.exe on that machine at some point. This causes builds from that machine to fail when deployed to the server, since the assemblies are not part of the package (since they were in the GAC in the machine that built the package). Technically, it makes sense from the .NET Frameworks perspective. I am including them as part of my project because the application will perform schema updates\rollbacks automatically. I am trying to understand why they are in the GAC in the first place. I thought maybe it had something to do with Visual Studio, but I manually removed them, which fixes my build\deploy problem and restarted VS2012, where all LightSpeed functionality (modeling, migrations, etc) appears to work correctly. Thanks, Bryan Migliorisi |
|
|
They are installed in the GAC for Visual Studio's benefit as in some situations it will not use the add-in's working directory when loading assemblies, so those specific assemblies which have been registered have to be available globally to cover that. I am not sure if this has been better resolved in 2012 as we originally set this up for 2008 where the problems originally presented and have just maintained that approach since then, so if it works - great! But we would certainly recommend having them GAC registered otherwise :)
|
|
|
Well it seems to be working without them in the GAC in VS2012. In the event that it doesnt work in the future, what do you recommend to deploy these assemblies? I have them referenced and also have Copy Local set to true, but does not matter when they are GACed. -Bryan |
|
|
Is this to support running migrations on the target machine? If so, you certainly do not need them GAC registered for this.
|
|
|
Yes it is to support that, however as I mention in the original post, when creating a web deployment package (or even just a simple project build), the assemblies are not included, because the compiler knows that they are GACed on this machine. The best thing I can think of is to manually copy the files over into the project /bin directories in my deployment scripts. Any other ideas? |
|
|
It does sound like you will need to manually cater for this since you have already tried explicitly referencing them and forcing them into the output folder via CopyLocal, presumably this is just restriction of the packager that it ignores things that are GAC registered. Sorry we cannot be of more help here :(
|
|