I'm currently rebuilding all our setup files (used to be .exe files) into MSI installers so that I can deploy them through Active Directory.
Basically, we have a tool (Windev for those who know it) that generates MSI files, but since our tool is limited, I generate .mst files (using Orca) to fine-tune the setup, and merge the source installer and the transform with msitran.exe. When I manually install the transformed setup file with /qb or /qn, the install works fine.
But when I try to add the setup file in the AD, I get an error message : "Unable to extract deployment information".
I found multiple solutions online, but none of them fit my problem (ie. I have all admin rights, my final MSI validates in Orca (with a couple warnings, but no errors). I get the same issue with the original MSI that our tool generates (but it doesn't validate in ORCA, hence the transform to fix that among other things).
Are there any properties that I need to set to successfully deploy my MSI to AD ?
Never mind, solution is plain stupid, but MS does not mention this anywhere.
Basically, it was an issue with the UNC path. My MSI was located in a path that contained whitespaces, and Windows Server 2003 apparently doesn't like that (wrapping the path in quotes in the open dialog does not change anything). Moving the files to a path without spaces fixed it.
Good day to all
Related
Using Visual Studio 2017 on Windows 10, I have a WPF application with an installer created using the Visual Studio Installer extension. When I install it on another PC, the application starts but then exits within the same second. Nothing in logs.
If I add a manifest to force admin mode, its starts correct.
If I copy the files to another folder (outside program files) it starts correct.
Apparently the "program files" is restricted or something? Am I missing something in my setup/installer project? Any other ideas more than welcome!
EDIT:
I've tried to create the installer using WIX and then it runs fine. Seems to be some settings in the VS Installer extension.
You can modify the ACLs on the folder in question to allow write access by regular users (not great) or you could write the settings file somewhere else where write permission for users is standard.
There are many ways: Resolve lacking permissions.
There is another, similar answer here.
Adding a couple further links:
WiX and deployment links, various topics.
I have created a GUI and Database for my company. I am trying to alpha test the program. I made the program so that everyone would place it on their C drive so that the file paths would stay consistent. When I email the zip folder to everyone it adds an extra folder that is causing errors to the file path (I believe the error occurs during extraction?). Does anyone know a good way to prevent this from happening? Thanks!
Although "xcopy deployment" is a valid method to deploy programs, it can come with complications, as you have discovered. Instead, you can create an actual installer program which is much more versatile.
For a lead-in on making an installer you can read Create MSI installer in Visual Studio 2017.
Make sure that the program uses locations as given in the Environment.SpecialFolder Enumeration so that it is automatically adapted for any (properly-configured) Windows installation.
Other installers are available, e.g. Inno Setup, which may offer simpler or more detailed configuration of some options like replacing or keeping older files, or installing prerequisites like a required framework version.
I have an SSIS File System deployment and I am trying to understand if there is any easy way to deploy a large number of packages. The name implies that it is a physical directory on the disk, that I could copy/paste the files to, but I cannot find anything online that tells me where this directory lives.
Am I correct in thinking it works this way? Or will I need to either manually upload each package in SSMS or script an automated deployment
Your current files reside in:
\[your]\[computer]\pdevine\Documents\Visual Studio [yourVersion]\Projects
After creating a solution on the target, you can just copy and paste the files into the project directory for the target. If you don't know where to find your current files, click on any package and look here:
We have a silverlight(5) project, the source in TFS (2010) and Continuous Integration build has been setup and working fine. However, we are now at the stage where we are trying to release it to some users to get them using it and give feedback. I've set up the code so that it checks for updates and if there are any it downloads the latest xap file. However this requires the xap file to be signed. No problem when doing this from our dev machines, but when it comes to the automated build it fails, with the message
Xap packaging failed. Cannot locate the signing tool SignTool.exe.
I've tried numerous things to get the signtool to be recoginised and can't. However, we don't actually need this on the CI build, so I've then tried a second tack which is to make the postbuild event conditional on being run in VisualStudio. Followed various suggestions here on SO but can't gett them to work.
The post build event is
if "$(BuildingInsideVisualStudio)" == "true" (
"C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\signtool.exe" sign /f "$(SolutionDir)castle.pfx" "$(TargetDir)Castle.xap"
copy "$(TargetDir)Castle.xap" "$(SolutionDir)Castle.Web\ClientBin"
)
still no joy. Have tried multiple variations of this, but keep getting the same message from the automated build.
So can anyone help with either a) getting the signing tool to be recoginised on the build server or b) getting the automated build to skip the postbuild event?
Found the problem in the end...
I had been putting in place some features so the app would download and install the latest xap file. This requires it to be signed. As this wasn't working I followed some instructions on signing a xap file, not realising that one of the other developers here had put in place the code I described above in the post build event.
I had mistakenly thought that this was created as a result of me checking the 'Sign The Xap File' check box.
So first issue was that other developer had not shared his pfx file with us to add to our certificate stores.
Second, and main issue, was that we then had two attempts at signing going on. The one via the check box and the one via the post build event. I removed the check box and it worked fine.
The issue with the check box is that it expects the SignTool.exe to be in a particular location. On our development boxes with full VS it is where it is looking for it, but on the build server it wasn't. Think it may also have something to do with 64bit machines.
By using only the build event (once you have the correct certificates installed) you can specify explicitly the location that the signtool is going to be, and if necessary install the windows sdk to that location.
This is the top result in Google for this error so updating it with my steps to resolve.
The above didnt work for me but performing the steps below should fix it.
Install the Windows 8.1 SDK on the build server (Windows 2008 R2 for me)
Adding the Windows SDK BIN directory (that contains signtool.exe, on my server) to the Environment PATH variable - e.g. c:\program files (x86)\Windows Kits\8.1\bin - note: Do not add quotes around this
Restart all the Visual Studio Team Foundation services in services.msc after you add the file path to the PATH variable as it needs to reload these before building
I am trying to make our SQL Server Integration Services packages as portable as possible and the one thing that is preventing that is that the path to the config is always an absolute path, which makes testing and deployment a headache. Are there any suggestions for making this more manageble?
Another issue is when another developer gets the package out of source control the path is specific to the developers machine.
If you are trying to execute your packages using Visual Studio then the configuration file path will be hardcoded in there. So if you move your project around you'll need to change the path in the package settings. To avoid this you could use the Environment variable option to store the configuration file path. Then you'll only need to change that.
For testing and deployment however you should probably use the dtexec utility to execute your packages. Make some batch files for that. Preferably one for each different environment. Here the configuration file path can be relative.
dtexec /File Package.dtsx /Conf configuration.dtsConfig
This is if you're packages are on file system. You can also store them in SQL Server. You can also store your configuration in SQL Server which may provide flexibility.
After several hours trying to make this work I found a solution here (not the best one, but it works)
Locate your configuration files (dtsconfig files) in the same directory as your solution file (.sln file)
ALWAYS open your solution by double-clicking the solution file (.sln file). This will set the ‘working folder’ to be where the solution lives, your configuration file will be read correctly
Otherwise the relative paths did not work for me.
Check out the free utility that can edit SSIS configuration file paths without BIDS:
http://ssisconfigeditor.codeplex.com/
My stock standard trick for these sorts of problems are mapping drives.
Either by using a mapped network drive or by using Subst (both methods are interchangable).
e.g. Map the location of your package to N:\ then inside your package use paths using N:\MyParentPackage.dtsx, N:\MyChildPackage.dtsx. The packages can be on totally different drives in different folders on different machines, it'll work once you map the package location to the N:\
I usually put a script along side the project files to map the drive, which maps the drive so it can be easily run before. One gotcha, if you're using subst on VISTA - Win8, map it for elevated and non-elevated.
I use the same approach for file references in Visual Studio projects. Only issue with this approach, you use to solve too many issues in your dev environment and you'll run out of drives letters.