Within my teambuild we use custom build process activities, which are deployed at
\BuildProcessTemplates\CustomAssemblies\MyActivities.dll
The build controller is configured to load the assemblies from that path.
If I checkin new assemblies, then the teambuild does not load the new assemblies automatically, but uses the old ones. In fact the latest build process template seems to be used, because I get the error:
"TF215097: An error occurred while initializing a build for build definition <myTemplate> Cannot create unknown type <any new type>"
If I restart the build controller services, then the latest assemblies are considered.
How can I get teambuild to load automatically the latest assemblies, without being forced to restart the controller?
Finally figured this out. Been driving me nuts for months. Even if your binaries are technically different (i.e. binary differences), it looks like agents only get refreshed if the file version is different.
So more specifically, in my version of "MyActivities.dll", I had to increment the following two lines in my AssemblyInfo.cs (old version string was 1.0.0.0):
[assembly: AssemblyVersion("1.0.0.1")]
[assembly: AssemblyFileVersion("1.0.0.1")]
Once I did that, I did a normal build of the assembly, then checked in the new binaries. Agents were refreshed with the new versions within minutes! :D
Other (less awesome) options if you can't update the version for some reason:
Check in a dummy file to the same dir. If any files are added/removed from the CustomAssemblies dir, it forces a refresh for all files
Change the "Version control path to custom assemblies:" value to some dummy value (doesn't matter where), apply the new value, then change back to the original directory. Any time the path changes, that forces a refresh for all files
The "Best" solution is to just update the file/assembly version, though.
Try to install MyActivities.dll into the GAC. I have all my custom assemblies in GAC and I didn't noticed any issues.
Related
I'm using Visual Studio 2010 for two applications, installing to IIS 7.5 on another server. Project A is a web forms web application, and Project B is an MVC 4 web application. During an attempt to set up StateServer between the two applications, I had added a reference to each's .dll in the other's References list. StateServer was abandoned in favor of using a cookie, and the project .dlls were deleted (I did not notice until the installation process that Project B's references were probably also in the list. VS seems to have deleted them from the References when the Project B.dll was deleted, since I did not delete those refs manually).
The problem is, the deployment package is still including them. (I'm just troubleshooting Project A, at the moment.) They are no longer listed in the project's References list, they do not appear in the folder contents under the obj/Release/Package folder, but they DO appear in the installed location after using Deploy -> Import Application in IIS! This includes Project B.dll, as well as many of it's references, such as DotNetOpenAuth.OAuth.dll.
I've run a search through my entire solution on Project A, and have no references to the Project B.dll. I've tried setting up a brand new site in IIS, and deploying to that. I've tried deploying under Staging (QA) and Release configurations, to make sure it wasn't just one of them that was messed up. Under Package/Publish Web, the settings you may be interested in are "Only files needed to run this application", and "Create deployment package as a zip file".
Running the site gives the error, "Could not load file or assembly 'System.Web.WebPages.Razor, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies". This dll is not in the References list of the project, nor the deployment Package folder, nor the installed location's bin folder. It runs with no error, locally.
If I simply remove the extra .dlls manually out of the installed location, I get a compilation error when running the site, complaining a variable is not declared: var lotid = <%=defaultLotID %>; However, this variable is very much declared in the code behind: Public Shared defaultLotID As Integer = 0. And like I said, it runs fine locally. So it seems like a bogus error; just a canary in the mine, maybe.
Seriously, what am I missing? I had no idea how hosed I would be after making a reference to another type of web application. Thank you to whoever takes on the challenge of troubleshooting this one! I'm two days in and coworkers are baffled.
I ended up undoing all my changes, putting my code back to the TFS last check in version. I reintroduced the just the cookie code, built and deployed, I no longer saw the other project's dlls in the installation location. I guess it wasn't going to work to move forward through the reference and subsequent backout. Had to rollback to the prior TFS version, and start over.
I'm currently working with InstallShield to deploy a .NET Winforms app. I am new to InstallShield and have not enjoyed the learning curve. The Winforms app has three related DLL's which are not getting updated during a minor upgrade. For a minor upgrade I am changing the version from 1.0.001 to 1.0.002 for example. The package code is being changed for each build automatically.
I have tried adding the dll's to the [INSTALLDIR] and setting the property to "always overwrite". For some reason this causes the upgrade to also not update the main exe.
Tried changing the product code to force a major upgrade. This installed a new version alongside the old version, but the new version still had the old dll's.
Tried changing ReinstallMode from "omus" to "vomus". This had no effect at all.
Tried using REINSTALL=ALL, REINSTALLMODE=vomus. This did not update the dll's and also caused new installs to fail with message that application "is not marked for installation".
Tried changing the version from 1.0.00x to 1.1.00x. dll's still not updated.
I notice that when I view properties of these dll files, they have File Version = 1.0.0.0 and Product Version 1.0.0.0. Do I need to manually increase these versions in order for InstallShield to recognize that they have been updated?
Use one component per file and set each file to be keyfile in its own component. This avoid all sorts of component referencing and file replacement issues. Be aware that multi-file assemblies must share the same component as they are intended as one "atomic" file system unit.
In addition you must also increment the version number for each build or set REINSTALLMODE to emus instead of the default omus. Never use amus.
My advice: go with the file version updates - it is much more reliable. Like you state the File Version is used, it must be incremented. I like to auto increment the build version number (last digit). It has been a while, but I think you just replace the number with * and it auto increments. I think you can do this from the Visual Studio project property view.
Maybe read up on the file versioning rules as well. Essentially versioned files are version compared, and for unversioned files the create and modify date stamps are compared and the file is replaced if it is unchanged on disk. More sample info.
Remove the "always overwrite" flag you enabled for all the files you enabled it for. This flag may work poorly with patches if you ever need them and also with other features.
When a major upgrade creates two side-by-side installations it hasn't worked. What you are left with are two different products installed at the same time. There is good inline help in Installshield itself with regards to how a major upgrade is set up. Which version of Installshield are you using? The version bundled with Visual Studio may not feature this help material.
A note on major upgrades and "reverted files":
A warning on a classic major upgrade issue: be aware that changed, unversioned files not set to be permanent on original install may be uninstalled during a major upgrade and then reinstalled yielding the impression that they have been replaced, but they are actually deleted and recreated. These are typically important settings files like XML files or similar - and people struggle with this issue a lot. Major upgrades are essentially a sequence. The old product is uninstalled, and then the new one is installed or vice versa. In the former case the files may be uninstalled first and then recreated. This does not happen in the latter case if component referencing is done right because the files that are matching between products are not uninstalled, but retained and then overwritten if need be (according to the file replacement / versioning rules).
I hope someone else has encountered this because its driving me batty.
I recently got a new laptop so I've been setting up my Visual Studio solutions (VS2010 with .NET 4.0) that I saved off my old machine. One of them is a simple console app that I use to simulate some things for testing. It references 2 assemblies that I have in another solution that I am working on now. This used to all work fine as expected but ever since moving to the new machine I get the dreaded "The type or namespace name 'YourAssembly' could not be found (are you missing a using directive or an assembly reference?" error message. The references are clearly shown in the Visual Studio but when the project builds it does not copy them to the bin directory which explains the message. Initially I was just referencing the dlls the way I would any 3rd party dll but I even tried removing that and including the project files in my solution and referencing them that way and still it fails. I've verified that the dlls have their 'Copy Local' property set to true and they do. Its really bizarre because the project references several other dlls that are just 3rd party assemblies (for example NLog, GData, etc) and those all copy over fine but not these two for some strange reason.
Here's one more piece of oddness. If I add some code to the console app that references my assemblies it says it can't find it. If I then re-add the assemblies to the references, the error disappears until I try to build it again and then it returns. Is this a VS bug or what? I've never seen this kind of odd behavior before.
thanks
One case that I have seen that caused the problems you are talking about:
Including references to dlls that are built in-house, linked to a specific version of the dll. Get a new copy of the dll (with a different version number) and the build breaks.
The solution in this case is to set the DLL reference property Specific Version to false. The version of the dll is ignored (in my case, it is safe to ignore it), and the build works properly.
I've also had weird errors like this where the NTFS permissions were set on the old file with an old login, but the new machine didn't like the old permissions.
Also, sometimes the old .sln or .csproj file refers to an odd file path that you can't seem to edit from within VStudio. Try opening those files with notepad and make sure the paths aren't broken. You can usually edit and save with fixed paths and things will work again.
Hans had the answer above but I was unable to find that post through searches so hopefully if you stumble upon this question I can save you several hours of frustration.
For some bizarre reason the 'Target Framework' was defaulting to ".NET Framework 4 - Client Profile" in the project properties. I double checked and it seems to do that whenever I create a new console app. It must be version related thing in VS because I hadn't encountered this issue previously in 2010.
To fix:
Right click on your project, choose properties
Under the main Application tab, set the Target Framework to be your framework of choice but NOT one of the 'Client Profile' options
Save and build as normal
Can ClickOnce be configured to delete off old published directories?
Or
Has anyone written some code that will delete off these publish directories (maybe keeping the last 10)?
Currently, every time a ClickOnce Publish is done a new directory is being created on the IIS Server. This NEW directory contains a copy of the whole application, which is downloaded. The old directories do not seem to be used anymore and is just taking up a lot of space.
Here is a sample of the directory names being created. As you can see the application version number is being used in the name.
EduBenesysNET_1_0_1_0
EduBenesysNET_1_0_1_1
….
EduBenesysNET_1_0_1_192
EduBenesysNET_1_0_1_193
We have had 194 (zero based) builds with each directory staying out there. With the size of one build being about 50mb, you can see how keeping the old directories out there will start to eat away at the disk space.
The way our application works is you always have to download the latest version. You do not have an option to skip the download so I am hoping that deleting off the old directories should not be a problem.
Good question (+1) - one would think that this should be possible somehow ...
Looking a bit closer though reveals that the observed publishing behavior is not actually a feature of the ClickOnce technology, rather one of the Visual Studio Publish Wizard - see for example section ClickOnce publish folder structure in ClickOnce Publishing Process:
If you manually generate or update a ClickOnce application publication using either Mage or a custom tool, you are not constrained to this folder and file structure. For any particular ClickOnce publication, the chain of dependencies includes the following: [...] [emphasis mine]
The Walkthrough: Manually Deploying a ClickOnce Application yields the same conclusion, i.e. the folder structure in use by VS is simply a (reasonable) convention/approach.
Unfortunately the VS Publish Wizard doesn't seem to offer deleting older versions indeed, at least it is neither visible nor documented somewhere. However, given the resulting folder structure is just an artifact of the build process, you might as well add a custom build step doing just that - figuring out the details (i.e. accessing the VS automation properties to derive the last published version etc.) is outside of the scope of your question though ;)
Regarding your sub question:
I am hoping that deleting off the old directories should not be a problem.
Definitely not a problem, it just depends on how many of these you want to keep for rollback operations eventually, see e.g. Can I delete previous old versions from Publishing Location created by ClickOnce?
The short answer is that this is not something that is built into Visual Studio or ClickOnce deployment, and you will have to find another way to do this, perhaps through a script that you run on your server.
You can delete all of the versions except the current one if you push updates as required updates. If you don't do that, you'll want to keep two versions in case the user reverts back a version.
After doing a subversion merge with a co-worker, my VSeWSS project no longer build correctly. It creates two features for a single webpart feature (before the merge, this didn't happen). If the name of the feature is "MyFeature', VSeWSS always creates a second folder called 'MyFeature_2' and adds it to the solution manifest.
I've tried deleting everything I know to delete: pkg/MyFeature_2, the entry from pkg/manifest.xml, and the incorrect feature id in pkg/solution.xml (which gets generated every time I build the wsp). I've deleted bin/Debug/solution. After that, I have no idea where VSeWSS is getting information telling it to add a second feature.
I've also tried completely removing that feature and re-adding it from scratch, but the same behavior persists. In the WSP view, the 'delete feature' button is enabled for the "true" feature, but disabled for the generated one. however, if I try to delete the true one, it fails and reports a permission error on pkg/MyFeature/.svn/all-wcprops.
Grr.
By default the /pkg directory isn't part of your Visual Studio project. So it doesn't get added to source control. You need to add this as it contains the GUID's for features and if you don't have it you'll find VSeWSS will silently create new GUID's and populate /pkg for you.
Regards,
Paul
It turns out that during the SVN merge, the pkg/MyFeature/feature.xml file got jacked up. A FeatureID was no longer specified, so every time it tried to rebuild, VSeWSS generated a FeatureID for it, which caused it to try and build out the entire feature again, but the folder that existed in the filesystem was in conflict with it. Once I restored the feature.xml for MyFeature, this problem was resolved. Now my problem is that I can't seem to get the package built - there may be a problem retracting the old solution, but that's something different.