Why Installer made with installshield hangs when deployed using ReleaseManagementBuild.exe? - ms-release-management

I have a build definition in TFS that compile my code, then using a post build event, I create a Setup.exe file using Installshield.
Using Release Management I am able to deploy the installer to a machine and start the installation process using the tool RunCommandLine, I add the required parameters to the setup.exe so it will install the application silently (using an answer file to avoid user interaction). This process works smoothly!!!
I want to go far, so I tried to launch a release from a gated check-in....change the build template, install the release management client in the build agent, configure my build definition......I performed a small change in my code, then a check-in.....it compiles in the server, and start the release process: deploy the installer and start the installation process using the tool RunCommandLine, I add the required parameters to the setup.exe so it will install the application silently.....but I got a timeout so the release was rejected. I check the machine and found that the setup.exe was still running 0% CPU usage.....very strange.
Checking the build log I found that the command line used by msbuild to launch the release process is something like this:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\Release Management\Client\bin\ReleaseManagementBuild.exe -tfs "http://tfs:8080/tfs/Mycollection" -tp "Project1" -bd "Mybuild" -bn "Mybuild_20150623_15.1.0.9" -ts "QA" -nologo
I ran it, and the behavior was the same: the installer got stuck...0% CPU Usage.....Release rejected by timeout.....
So...I open Release Management Client look for the recently created release, and click in the option "Retry failed deployment"....It works!!!! the installer install!!! it does not hangs!!!
I was able to reproduce this behavior several times:
Release launched from Release Management Console......Works
Release launched from ReleaseManagementBuild.exe .......Does not works (Setup.exe hangs)
Any suggestion??

Related

MSB4062 error publishing .NET7 app with publish profile

This is pretty easy to replicate but also code here:
https://github.com/dominicshaw/dotnet-publish-error
create an empty wpf project using .NET7
create a publish profile for ClickOnce
publish via command line (not visual studio)
Publish profile is almost totally standard (view here)
Command line from project directory:
dotnet publish PublishError.csproj -p:PublishProfile=ClickOnceProfile
Subsequent error:
MSBuild version 17.4.0+18d5aef85 for .NET
Determining projects to restore...
All projects are up-to-date for restore.
C:\Program Files\dotnet\sdk\7.0.100\Microsoft.Common.CurrentVersion.targets(4149,5): error MSB4062: The "Microsoft.Build.Tasks.RequiresFr
amework35SP1Assembly" task could not be loaded from the assembly Microsoft.Build.Tasks.Core, Version=15.1.0.0, Culture=neutral, PublicKey
Token=b03f5f7f11d50a3a. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, a
nd that the task contains a public class that implements Microsoft.Build.Framework.ITask. [C:\Users\shawd\source\repos\PublishError\Publi
shError\PublishError.csproj]
I have the latest SDKs installed and VS2022 up to date. This only happens via command line - I am able to publish from Visual Studio (I am setting up devops, so require command line).
This happens regardless of adding nuget package for Microsoft.Build.Tasks.Core. Note however nuget package v15.1.0.0 is not available - I have tried 15.1.548 and the latest instead.
Totally at a loss! Any ideas very welcome.
Thanks vm
During the tests with your project and files, I finally managed to publish it successfully with the command dotnet publish PublishError.csproj -p:PublishProfile=FolderProfile.
Here is the document for dotnet publish, as is referred,
The preceding example uses the FolderProfile.pubxml file that is found
in the <project_folder>/Properties/PublishProfiles folder. If you
specify a path and file extension when setting the PublishProfile
property, they are ignored. MSBuild by default looks in the
Properties/PublishProfiles folder and assumes the pubxml file
extension.
And I also succeeded with dotnet publish with your project.
==============================
update on 11/19
So I suppose that the issue is resulted from your definition for -p:PublishProfile=ClickOnceProfile,it will change the path where this command would search for the publish file
A partial answer as my workaround for anyone struggling with a similar problem:
I have found it impossible to do this with the dotnet cli but I can do it with MSBuild if I specifically target 17.4 (VS2022). By default, my Azure DevOps Server 2020 capability is the 2019 MSBuild (15.X), so I have to be explicit:
"C:\Program Files\Microsoft Visual Studio\2022\Professional\Msbuild\Current\Bin\MSBuild.exe" /restore /Verbosity:m /t:Publish /p:RuntimeIdentifier=win-x64 /p:configuration=Release /p:PublishProfile=ClickOnceProfile
This works - so in my pipeline I have created a batch file which runs this, then I copy the files to my ClickOnce location.
Not ideal, but a working pipeline.
Interesting side note - this dotnet cli command which should be idenitical (and indeed uses the correct 17.4 MSBuild) - does not work (with the same error):
dotnet msbuild -target:Publish -property:RuntimeIdentifiers=win-x64;Configuration=Release;PublishProfile=ClickOnceProfile

Project build halts on: "Build delayed until Bower/npm packages finish restoring."

In VS 2017, I created a new ASP.NET Core Web Application using the Angular template.
The project however does not run, it gets stuck on:
Build delayed until Bower/npm packages finish restoring.
I see that a background task is running, but this goes on for ever and doesn't make any progress.
I had a similar problem and I followed the below steps to get around it.
Disable Package restore:
Go to Tools -> Options -> Project and Solutions -> Web Package Management -> Package Restore.
Set False to 'Restore on Project Open' and 'Restore on Save'
After disabling, I opened a terminal and manually installed all the packages. I used Yarn to install the packages and faced no problems.
Visual Studio often halts during project builds because of timeouts. To get around that, I used the command yarn --network-timeout 60000.
Hope this helps!
i had a sort-a-like problem. This is what i did to solve it:
check the folder node_modules
on my pc it was empty
open the folder in a command prompt (with administrator privileges)
run "npm install", this will download all referenced node modules
(see package.json) to your pc
then when you build in VS Studio,the bower delay is gone
I was able to workaround my indefinite “Build delayed until Bower/npm packages finish restoring.” publishing delay in VS.NET 2019 Community Edition by:
Clicking on the [Cancel] button in the [Web Publish Activity] tab.
Exiting and restarting VS.NET with Administrative privileges
Opening the solution and publishing my app again.
In my case, it looks like it was the lack of Administrative privileges that caused the infinite delay.
For react project I solved it using these steps.
1) right click on the project and select >build
2) Then in output box showing "Build delayed until Bower/npm packages finish restoring."
3) Wait few minutes.After building the project you can see
Build delayed until Bower/npm packages finish restoring.
1>------ Build started: Project: chatApplication, Configuration: Debug Any CPU ------
1>chatApplication -> D:\IdeaProjects\chatApplication\chatApplication\bin\Debug\netcoreapp2.1\chatApplication.dll
1>chatApplication -> D:\IdeaProjects\chatApplication\chatApplication\bin\Debug\netcoreapp2.1\chatApplication.Views.dll
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
I had some problem in visual stduio 2019 aspnet core & angular project.
I have solved it using this way.
Manually run npm install via cmd,
And if after run project via visual studio 2019, Project run successfuly. (Without “Build delayed until Bower/npm packages finish restoring.”)
This way worked for me

SSIS C# 2012 Script Task referring WinSCPnet.dll fails when run from SQL Server Agent with "Exception has been thrown by the target of an invocation"

I have an SSIS package (created in VS 2013) that contains a C# 2012 Script Task.
The job of the script task is to download a file from an SFTP server using WinSCP .NET assembly and place it on my server (Windows Server 2012 R2 with SQL Server 2014)
My package runs fine when I run it on my Dev machine, but when I deploy to the server my package fails at this task with the error message
Exception has been thrown by the target of an invocation
I've done some digging and it looks like it has something to do with the reference to WinSCPnet.dll.
Quoting WinSCP article on Exception has been thrown by the target of an invocation:
This is just a high-level exception. The root cause is usually stored in the InnerException.
If you are getting this exception in SSIS, you can use try … catch block to capture the error, as show in the example for using WinSCP .NET Assembly from SSIS.
If you cannot access the inner exception easily, inspect WinSCP session log and debug log file (Session.SessionLogPath, Session.DebugLogPath). If those file are not even created, the root cause can be loading of WinSCPnet.dll assembly. See Could not load file or assembly ‘file:///…\WinSCPnet.dll’ or one of its dependencies. The system cannot find the file specified..
Installing the assembly to allow its loading is covered in Installing section of Using WinSCP .NET Assembly from SQL Server Integration Services (SSIS):
Installing
First, you need to install the WinSCP .NET assembly. Do not use the NuGet package.1
You also need to install the assembly to the GAC or subscribe AppDomain.AssemblyResolve event to allow loading the assembly.
The installation to GAC is covered by Installing to GAC section of Installation instructions for WinSCP .NET assembly:
Installing to GAC
In special cases, you may need to install the assembly into Global Assembly Cache (GAC), particularly to use it from SSIS.
When you install the assembly to GAC, you need to configure a path to WinSCP executable.
On Development Machine
To install the assembly into GAC on development machine, i.e. the one that has Windows SDK installed, use following command:
gacutil.exe /i WinSCPnet.dll
Windows SDK comes with Microsoft Visual Studio. You can also install it separately.
Use correct gacutil.exe for your version of .NET framework:
For .NET framework 4.0 or newer, use gacutil from Windows SDK 7.1 (or newer):
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1\bin\gacutil.exe;
For .NET framework 3.5, use gacutil from Windows SDK 6.0:
C:\Program Files (x86)\Microsoft SDKs\Windows\v6.0A\Bin\gacutil.exe
On Production or User's Machine
To install the assembly into GAC on production or user’s machine, you may install the assembly into GAC using:
Windows Installer, by creating .msi package;
Any other installer system that supports installing to GAC, e.g. Inno Setup;
System.EnterpriseServices.Internal.Publish.GacInstall method. PowerShell example:
Add-Type -AssemblyName "System.EnterpriseServices"
$publish = New-Object System.EnterpriseServices.Internal.Publish
$publish.GacInstall("WinSCPnet.dll")
An absolute path to the DLL needs to be specified and Administrator privileges are required. Otherwise the above method will fail (and the only indication of the failure is sent to Windows Event log).
See How to fix NuGet WinSCP.NET in SSIS Script Task?
You need to install WinSCPnet.dll in the Global Assembly Cache for SSIS to pick up this dependency, see this blog for further details. You can install a DLL in the GAC using the following steps, see the documentation for further details:
Copy the WinSCPnet assembly to your local computer into a folder.
Start Visual Studio Command Prompt.
Type the following command: gacutil.exe /if ""
This installs the assembly to the GAC, overwriting any existing assembly that has the same assembly name.
If you have already registered the appropriate Dll's are are still getting this error, and you are passing in variables that are package-scoped, be sure to add them to the "ReadOnlyVariables" in the script task.
Right click on the task and click "Edit...", then click the "..." on the "ReadOnlyVariables" property, and add the variables that are referenced in your script.

Headless build .sqlproj file on TFS build server

I'm attempting to build a .sqlproj on a TFS Build Server. I've followed the instructions here:
http://sqlproj.com/index.php/2012/03/headless-msbuild-support-for-ssdt-sqlproj-projects/
which I was directed to from here:
How to build .sqlproj projects on a build server?
But I still cannot build. The error is:
C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets
(441): The "SqlModelResolutionTask" task could not be instantiated
from "C:\Program Files
(x86)\Common7\IDE\Extensions\Microsoft\SQLDB\Dac\120\Microsoft.Data.Tools.Schema.Tasks.Sql.11.dll".
System.TypeInitializationException: The type initializer for
'Microsoft.Data.Tools.Schema.Tasks.Sql.DataTask' threw an exception.
---> System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Data.Tools.Schema.Sql, Version=12.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The
system cannot find the file specified. at
Microsoft.Data.Tools.Schema.Sql.Extensibility.ToolingShim.ConfigureExtensions()
--- End of inner exception stack trace --- at Microsoft.Data.Tools.Schema.Tasks.Sql.DataTask..ctor()
The SqlTasks.targets file, used by the SQL project, references this:
C:\Program Files (x86)\Common7\IDE\Extensions\Microsoft\SQLDB\Dac\120\Microsoft.Data.Tools.Schema.Tasks.Sql.11.dll
which in turn references the invalid version mentioned above.
However, the files installed by the process in the link above don't install this version. They do install version 10.3.0.0, which is referenced by
C:\Program Files (x86)\Microsoft SQL Server\110\DAC\bin\Microsoft.Data.Tools.Schema.Tasks.Sql.12.dll
but this file is not the one used by the .targets file.
I don't know what the numbers at the end of this dll mean, but it seems odd to me that the one ending 12.dll references an earlier version of the one ending 11.dll.
I'm using Visual Studio 2013 and SQL Server 2012 - neither of which are installed on the build server, which I believe is the recommended situation. I don't know what the IDE folder is, or why the .targets file is using it.
I've spent about two days now trying to get this to build, but I'm out of ideas. Anyone know what's going on?
If you are running VS2013 SSDT is built into VS as long as you select it on the install screen. Install VS2013 with SSDT onto your build server. create a build definition and under Process > Build > Advanced Add the following to the MSBuild arguments to build the sql proj
/t:Build
if you have a publish profile and want to test publishing to SQL then add the publish switch and provide the link to the profile file
/t:Publish /p:SqlPublishProfilePath=MyDB.publish.xml.
this will publish the db to the server specified in the publish file.
the publish profile file can be created by opening the project in Visual Studio, right click on the project and select publish. Select save once you are happy with the publish options and then check in the file to source control so the build can find it, (project Root).
I was having this issue building a SQL Server project on an Azure DevOps CI/CD pipeline. None of the pre-built build tasks would work for me. And it is not possible to install a VS instance on the build server, I guess.
I solved this by avoiding to add a SQL Server project to the solution.
I achieved this by using an MSBuild SDK, capable of producing a SQL Server Data-Tier Application package (.dacpac) from the set of SQL scripts. By adding this second project to the solution, I managed to continue taking advantage of linking the project to a live database through SQL Server Object Explorer on Visual Studio. I gave a more detailed explanation in this answer.

How to install Crystal Reports for .Net 3.5 Winforms application

We have a VB.Net Winforms (x86) application that uses the freely redistributable version of Crystal Reports. Although the application works fine on my test machine, when installing on a client's machine and trying to print a report from the application, the error: The system cannot find the file specified. File name: 'CrystalDecisions.CrystalReports.Engine ... is displayed.
The inno-setup includes the CR redistributable "CRRedist2008_x86.msi" which was installed by the client during the installation. (We also tried running the "CRRedist2008_x64.msi" but received an "unsupported processor type" error).
I have read about Merge Modules that are prerequisites for .NET 1/2 (VS 2002/2005), but cannot find any useful information related to .NET 3.5 and am wondering if these files are still required and how to package and deploy them if they are in fact needed.
Any guidance on how to resolve this installation issue is much appreciated.
Edit
The Inno-Setup contains the following command that checks to see if CR is installed and if not the MSI is launched from the final setup form:
[Run]
Filename: "{app}\CRRedist2008_x86.msi"; Description: "Crystal Reports"; Flags: nowait postinstall skipifsilent; Check: EnsureCrystalReports105Installed();
The problem is that you are not actually executing the MSI file. You can see this by running your installer with /LOG and reviewing the resulting log file.
This is because MSI files cannot be directly executed -- they're data files, not programs.
To resolve this, you need to run msiexec instead, passing the MSI file as a parameter; eg.
[Run]
Filename: {sys}\msiexec.exe; Parameters: "/i ""{app}\CRRedist2008_x86.msi"""; ...
You should review the command line parameters accepted by msiexec and properties accepted by the MSI file to see if you want to do something different, eg. running the install silently instead of interactively.
Also, running it as postinstall is fine if this component is optional for your application and it can gracefully handle it not being installed. If this is not the case then you should treat it as a prerequisite instead and always install it via PrepareToInstall.

Resources