I inherited a project, that was just a modified sample project from Honeywell.
Whenever you make a build, you have to uncomment lines for variables setting the client, the server url, and the device the build is being made for. Then, you need to go into the solution's Cab project, and change the application name (based on client / server), and change the shortcut's name to match. After the build, I then need to rename the CAB file it created. And usually I have to do this for a combination of 5 servers, 3 clients and 2 devices.
It's all very redundant. My absolute ideal would be to pick each ( or the combination "Client Server Device" ) from a dropdown ( such as the configuration ), then simply make the build. Most of my googling around suggests I can make this much more streamlined using "Configurations", but I can't seem to find instructions on how to actually set it up.
I am limited to Visual Studio 2008 due to .NET restrictions (v3.5) on the Honeywell SDK.
Any help would be greatly appreciated.
You need to separate out build-time parameters (baked into the code at build time), from install-time parameters (determined when the software is installed), from run-time parameters (configurable at run-time, e.g., after installation). Typically things like server urls are environment specific and are should therefore be determined at install-time, not at build-time as this project you inherited seems to be doing. You need some sort of installer to enable the configuration of the install-time parameters, and possibly an administration utility to enable the configuration of any run-time parameters after installation.
The goal is to be able to build once, but install many times (into different environments with different configurations).
There are a lot of tools available to help with this. This is a list of build automation tools: https://en.wikipedia.org/wiki/List_of_build_automation_software#Continuous_integration_tools. And here is a list of tools for writing installers: https://en.wikipedia.org/wiki/List_of_installation_software.
Related
I keep running into an issue with our TFS build server. I've got 2 projects (both in the same solution), 1 is a WebForms project, running .Net 4.0. The second is an ASP .Net MVC5 project running .Net 4.5. There is also a Silverlight project, but the problem is reproducible with just the first two.
Both of these projects use NuGet packages for various libraries. Sometimes there are different assemblies within a package for their respective environments. A .Net 4.0, 4.5, SL assembly, etc.
The build server seems to dump all of the libraries required into a single folder, then pulls from that to build the solution. This causes problems in many cases, with the wrong project getting the wrong assembly version. This does not occur locally, only on the build server. I can't figure out what I need to do to keep this from happening. Any ideas?
Yes, I hate this standard behavior, but TFS will output everything to the same folder by default, and then you will get various errors depending on which order msbuild compiles your projects if you have references with the same name or even project outputs with the same name.
The easiest workaround is to use the AsConfigured option on the Process tab, '2. Build' -> 'Output location' of the build definition window. This keeps your normal source structure intact, but I think you will lose support for automatically dropped outputs (i.e. you will have to provide a script to do that yourself). If you are only using TFS Build for validation, this is the cleanest approach.
You can also use the PerProject setting and split up your projects into two distinct solutions, perhaps suffixed by platform (we've done that numerous times in our company). Then, you specify both solutions to the build process and it will create two separate folders in the output, one for each solution.
This is all assuming you are using TFS 2013. In TFS2012, there is a similar option but it is in '3. Advanced' -> 'Solution Specific Build Outputs'. You will probably have to go this route if you are using TFS2012 or you will need to modify the default workflow yourself to add your own logic.
EDIT:
From your comment to the other poster I see you are using TFS 2010. Well... I think this was absolutely not supported at that time, I remember having similar problems, but we upgraded to TFS 2012 and all was well.
I think your only option is to either create two separate build definitions and build each solution that way, or you will need to checkout the xaml workflow and edit it with your own logic. Perhaps downloading the TFS2012 template and "porting" it to TFS2010 would be a better approach since at least you would not be reinventing the wheel that way.
How can i install windows installer for 64 bit? I am getting the following error while building the setup file in InstallShield Limited Edition.
As for your errors, they can be caused by something as simple as having the directory open in an explorer window (try closing it a rerun). And have a look at this old IS KB Article
Another possible cause is your Setup PreRequisite file, see this link
"Error appears (in Installshiled 12) if during editing a .prq in Setup Prerequisite Editor select the check-box "Requires Windows Installer engine and/or .NET Framework to be installed first" and after deselect this option. After that in prq-file appears empty section "dependencies", which incorrectly, probably, processed by the builder. It is necessary to remove this section (in any text editor) to avoid an error. "
With regards to your warning:- Have you setup the software id tag ? the following is taken from here Especially read the part I've put in bold.
To include a software identification tag in your installation:
In the View List under Installation Information, click General Information.
In the Software Identification Tag area of the view, modify the values of the settings as needed.
The Use Software Identification Tag setting lets you specify whether you want to include a tag in your installation. Select Yes, which is the default value, and then configure the other settings in the Software Identification Tag area as needed.
When you use tagging in your project, InstallShield adds the tag to two new components that it creates, and it associates the components with one of your project’s features. The components are:
ISO19770_LocalTag, which has a destination of INSTALLDIR
ISO19770_SystemTag, which has a destination of CommonAppDataFolder
Use the Setup Design view if you want to associate these components with a different feature in your project. For more information, see Component-Feature Associations.
At build time, if the following conditions are true, InstallShield includes the software identification tag with the installation that it builds:
Yes, the default value, is selected for the Use Software Identification Tag setting in the General Information view.
The Unique ID, Tag Creator, and Tag Creator ID settings in the General Information view have values.
Note that if tagging is enabled but you have not entered values in one or more of the three aforementioned tag identification settings, InstallShield generates a build warning to inform you that the tag could not be included in your release. To resolve this warning, configure the settings in the Software Identification Tag area of the General Information view as needed.
If you configure your project to include a software identification tag and you also configure the release in the Releases view to use a .pfx file to digitally sign your release, InstallShield digitally signs the tag at build time. Note that the .NET Framework 2.0 or later must be installed on your build machine in order to sign a tag file.
Leaving the stuff below, but looking closer at your screenshot it looks like it's claiming certain files aren't in folders where it's looking... I don't think that has anything to do with installing the file to your system as your system isn't Vista, XP, AND Server 2008 (at least I would assume you aren't running three OS at the same time lol). I could be wrong, but this sounds like an import problem... it looks like it's trying to import those files as files your user needs to install your program... you need to get those 3 installers and then import them (package them, whatever this program you are using does) as prerequisites. That SHOULD solve the problem.
--------------Probably not applicable but if above is incorrect----------
Simple suggestions... unlikely, but my usual troubleshooting steps when all else fails.
Check your file paths.
Double check that you ARE installing the version for 64bit.
Your harddrive isn't full is it?
Turn off virus scanners.
Try installing in safe mode.
Run a virus scan (use something good like Malwarebytes).
Check the Windows error log.
If you downloaded it on a different device try downloading it on the computer you want to install it to.
Download the installer on a different device.
Run as Admin or from a new user account.
Change the folder you are running the installer out of... try running the installer right out of c:\
Install it through Windows Updates (I'm just assuming Win 7 has them, I avoid windows update).
Make sure you have all the .NET frameworks installed (I've seen odd things happen when you don't)
Run the installer on a different computer to make sure it works.
Found this through Google... http://winhlp.com/node/40 the bottom of the page shows some software that can contribute to this error... it may say 'server' but I'm sure that even if the computer isn't networked these can still cause the problem...
Is there an easy way to configure different configuration files for publishing with click once in a WinForms application? I'm looking to create a Settings/app.config depending on the solution configuration, ie: Debug/Release, and have the same setting keys, but pointing to different machines/db's for development/production connections for each solution configuration.
Thanks,
Mark
Sadly, unlike ASP.Net VS2010 does not support different config files for Debug/Release. Its frustrating that the various VS teams don't co-ordinate a little better as the feature in ASP is very useful.
Really, the only place to change the app.config for your debug vs release is in your build process after running msbuild.
I wrote and sell a piece of software called ClickOnceMore that supports different environments (debug, staging, QA, production etc) using a macro approach. You can define a different value for each macro depending on the build type (which can be passed in on the command line). You can then use the value of those macros to either pick up a different config file or to replace values in a config file template.
A simpler approach in ClickOnceMore lets you use the built in macro [DebugOrRelease] to pick up a different config file for Debug or Release builds.
You can download a free trial of ClickOnceMore here: www.clickoncemore.net if you have any problem making your scenario work just let me know, it should be able to do exactly what you want to do.
I am looking for a very simple update tool that can be sent out to various sites and update their applications and database.
I need the tool to be configurable by non developers. I.e. support staff.
The tool will need to be able to copy DLL files into the program location.
It should be able to find the program location, and read in the configuration file to find the database location and connection details.
It should be able to update the configuration files.
If this tool can support roll back it would be an added extra.
I am not looking for a tool like install sheild etc. as this will require a developer to use.
Open source projects, freeware or commerical applications are all acceptable.
If you have any idea, tips or suggestions they are all welcome.
This is the classic use case for having an installer for your application. The installer will copy your DLLs etc into a folder. You can then author updates or patches which can do an update of your application with newer files.
I'm not sure what you mean by "developer use". Do you mean a developer would have to create the installer project? If so, that is not really true. but yes, they would have to learn the tool is it is support you want authoring your install/updates.
There are some free tools to build windows installers. Wix is one and Inno Setup is another.
As far as updating SQL databases, Red Gate's packager is pretty simplistic. It does nothing more than wrap an update script into an executable. You can do this on your own of course if you have a tool to create a change script. The problem here is that the target database must always match the one you generated the change script on.
We use DbGhost PackagerPlus. This tool actually bundles the compare engine so that the target database can be any previous version and it will still be updated. The packager call also be called from the command line so you can run it from your installer.
I have a C# console application written in Visual Studio 2008.
Usually I just build the application and then copy the files from the 'Release' folder but this time trying to do it 'properly' by publishing the application.
I went through the 'Publish Wizard' and end up with a 'Setup.exe' file in the specified folder. When running this setup file on another computer the install fails and indicates via a error message that:
Cannot download the application. The Application is missing required files...
When I select the 'details' button the error log shows that the program was trying to download files from the last version directory (ie 1_0_0_4).
What am I doing wrong? (aside from being tired...)
Show I de-activate the version auto-incrementing?
Unless you have a valid reason to do so, I would abandon the publishing and just go back to the XCopy installation. (And by Valid, I mean something other than someone told you that it's the "proper" way to do it.) I base this advice on the following arguments:
We used ClickOnce for all our WinForms apps for a while, but eventually it got to be more trouble than it was worth. For one thing, you need to deal with the security certificates. We had issues when we replaced a server with a new one with a different name, then we had issues when we replaced our development machines, etc.
You said this is a console application. ClickOnce publication seems to be overkill for a simple console application unless there are third party dependencies that you need to include in your install.
Don't get me wrong, I liked using ClickOnce for the ease of putting updates out there, and we use it still when it's the best option. However, in your situation, it looks to me like XCopy deployment should be sufficient for a simple console application.
Not knowing what you choose in the wizard, web or CD, the setup.exe file needs to be able to reference it's installation files. If using the CD method, you will notice in the output directory you revision directories, e.g. 1_0_0_4, where each revision of your app is kept. I agree with #David_Stratton, and unless you really need to use one-click publishing, don't. Just use xcopy (robocopy), zipfiles, etc. It will greatly reduce your stress levels down the road.
Everything David Stratton has stated is correct. ClickOnce is overkill for what you're trying to do, and publishing through Visual Studio has always given me headaches.
I might recommend taking a look at NSIS if you're looking for generating an installer for others. It's relatively simple to generate full installers that merely grab files from your /Release/ directory, with plenty of sample code for getting an installer working quickly. Once you have your working script, making your installers are as simple as a right-click and clicking compile.