I have InstallShield 2013 Basic MSI project
Is there an automatic way using a tool or script to automatically update all component code in the project ?
First question: why do you want to do that? A component GUID is set in stone for all absolute paths it references. See a description of this here: Change my component GUID in wix?
If you are familiar with COM automation, you should be able to automate the generation of new GUIDs in your project using the Installshield automation interface.
There are only a few cases where such an operation is logical and valid. If you are looking to install the same product many times, you can check out instance transforms. I have no real experience with this - I dislike the concept, but here are some pointers:
Installing Multiple Instances with Instance Transforms
Authoring Multiple Instances with Instance Transforms
Configuring and Building a Release that Includes Multiple-Instance Support
Multiple Instances Tab for a Product Configuration
Related
I'm new in docusign.
Currently I'm working on Form development etc..
Can someone tell me where in docusign in Workflow diagram can I create or use own c# class or DLL.
Currently in a calculation stage we are creating many c# functions for field calculation but it must be there an option to use object oriented programming?
Thank you for any help, clue!!!
You can either use a Nuget package directly, that is found either using Nuget Package Manager or directly - https://www.nuget.org/packages/DocuSign.eSign.dll/
Or, you can clone this repo and build it yourself and add it as a project in your solution.
If you want to see some code that is using it and try it out - go to https://github.com/docusign/code-examples-csharp.
I want to be able to build 30+ packages in SSIS and be able to test/develop them in isolation. I also want to be able to run these from a Master/Parent package.
When it comes to delivering the SSIS parent package I want to be able to change the connection string once and have this trickle down to all child packages. Other developers will be building and testing without using the master package and want to be able to develop these in isolation.
I've seen many articles on XML config/parameter mappings etc. but I've not seen any definitive guide on how this should be done & what is best practice.
The project we have created also only allows packages to be linked in the solution as an external reference rather than as project links (is this the legacy format?). I'm wondering if this type of project could hamper the ability to achieve shared connection strings.
Answering this myself for reference. Basically there is no streamlined way of doing this in the Package Deployment model. It is much easier to achieve this using the Project Deployment model which is the default in VS2012. However, we don't have this luxury.
I had to create some parent variables contained in the master package. These are then set to the XML config. The child packages then have direct config links to the parent variables, with the target properties mapped to the connection string properties of the connection managers.
I have a database project in Visual Studio 2012 with SSDT (latest as of this writing). In the database project, I have a schema called "UNITTEST" which contains tons of stored procedures that create, destroy, and provide other helper functionality for the unit tests. We do this because it gives us the ability to control our test data centrally rather than inside each unit test. Now that's fine and all however, I don't want to publish this schema or any of the objects inside of this schema to production.
So my question.. Is there a way to stop SSDT/VS2012 from including the UNITTEST schema in the production build deployment script?
I'm thinking there should be a way to do it depending on the solution configuration settings and publish profiles. If my configuration is set to "Release" then I want the build to perform a bit differently.
Builds are very new to me. I found this question: build-different-scripts-depending-on-build-configuration but I can't seem to get the answer to fulfill my problem. This question also doesn't help although it's very similar: bind-the-deploy-and-publish-destination.
Is anyone else managing something like this? The other developers in my team are just modifying the published script to remove these objects but I HATE manual work, there HAS to be a solution! :)
Thanks all!
One of my schemas references a lot of sys.* objects which created a lot of errors in the build. I created another project in the solution and moved that schema to the new project.
Luckily you can build and publish at the project level.
This allows me to keep the other schema in change control at least.
(It may also help to set the Properties on the SQL files to Build Action: None)
Partial/Composite projects might be useful here. Main project contains all of your necessary DB objects for your apps to run. The partial project references the main project, but then contains all of the "Test" code.
Here are a couple of options from Jamie Thomson:
http://sqlblog.com/blogs/jamie_thomson/archive/2013/03/10/deployment-of-client-specific-database-code-using-ssdt.aspx --This may be the simplest way to handle this
http://sqlblog.com/blogs/jamie_thomson/archive/2012/01/01/implementing-sql-server-solutions-using-visual-studio-2010-database-projects-a-compendium-of-project-experiences.aspx --Lots of good information in this post and most of it also applies to SSDT SQL Projects.
http://msdn.microsoft.com/en-us/library/dd193415.aspx - Composite projects for larger DBs. This could potentially work for you as well.
I am maintaining a set of eleven Windows Store apps. I would like to automate the "Create Package" task, which I am currently doing through the wizard in Visual Studio, in order to produce test packages (signed with my test certificate).
Is there a way to script this task? I was thinking probably using MSBuild or PowerShell, my goal is to have a single script to run that would generate all my app packages and copy them all to a given target directory.
I found some documentation about using the wizard on MSDN, but nothing about scripting the task.
Any ideas?! Thanks.
MSBuild will create app packages for you, in the AppPackages folder. You can also do it manually using MakeAppx, but I've found it to be a bit more cumbersome.
Some things to note: There is a build target called Publish you should use (/t:Publish) when making the actual packages. You should look into the different command-line switches, such as DebugSymbols.
You'll likely want to use the 32-bit MSBuild, as I've had issues with the 64-bit and things like the Multilingual App Toolkit. Also in regards to the MApp Toolkit, make sure you do a full rebuild before building your app package. If an entry is not in a given language and is in another, the entry for the secondary language will be used, so you can end up with multiple languages all popping up on the same page.
Hope this helps and happy coding!
I came across some vague information about creating an ICE for an InstallShield project, but I don't understand what they are used for. How does an ICE test an installer? Can it be used on InstallScript projects? InstallScript MSI projects?
Is it like a unit test framework?
ICEs are made of custom actions that evaluate static data in a built MSI file. They check things that need to be true, but the database schema cannot enforce. In this sense, it's somewhat like a unit test for a database, but doesn't test a lot of things, such as any of the code for custom actions. InstallScript projects do not create an MSI, so ICEs cannot be used; however InstallScript MSIs do create an MSI.
The information you came across likely suggests using them to enforce additional business rules you may have. For example you could write ICEs to check that INSTALLDIR uses your company's name, or that all .myext files are not installed beneath ProgramFilesFolder.