I am try to digitally sign .dll, .exe and .msi files using signUserFiles.exe, I have configured signing steps into Cruise control tool and when I try to build our project (abc.proj file) using cruise control tool then I am getting below error
EXEC (0,0): error: Unable to find the temporary location for signtool. Exiting...
c:\work\UCA7.3_8.1GA\Client\Sign.targets (31,6):
errorMSB3073: The command "C:\Programs\Signing\Windows\signUserFiles.exe -as -fd sha256 -file c:\work\UCA7.3_8.1GA\Client\UCA\bin\Release\53xxPCApp.exe" exited with code 1.
I have written commands as below
while same is working fine if I build abc.proj directly from command prompt window using "msbuild abc.proj" command
Please help me
Regards
Ganesh
SignTool docs can be found at https://learn.microsoft.com/en-us/windows/desktop/seccrypto/signtool
On my dev VM, I see signtool.exe in the following locations:
C:\Program Files (x86)\Windows Kits\10\bin\x64\signtool.exe
C:\Program Files (x86)\Microsoft SDKs\ClickOnce\SignTool\signtool.exe
I am not familiar with "SignUserFiles.exe" but I always use the Win32 SDK exe and perhaps havent stumbled across that file name. I always run signtool as a CC.Net "executable task". A little more work perhaps, but I prefer granular control of these things.
See https://ccnet.github.io/CruiseControl.NET/projects/ccnet/wiki/Executable_Task.html for details re: the executable task.
Related
Publishing the ClickOnce application via msbuild using command
msbuild /t:publish /p:BootstrapperEnabled=true;PublishDir=C:\publish\;PublishUrl=C:\publish
Throws the error:
error MSB3484: Signing target 'bin\Debug\app.publish\setup.exe' could not be found.
No setup.exe is generated, whereas publishing via Visual Studio IDE generates the setup.exe to the specified folder.
Have looked over the net and found the below solutions
To enable BootstrapperEnable = true,
To specify \ at the end of PublishDir/PublishUrl
And the above solutions don't work for me. Any suggestions would be highly appreciated.
Below command worked:
msbuild /t:publish /p:PublishDir=C:\publish\ /p:ApplicationVersion=1.0.1.1
Din't have to specify the InstallationFolder, since ClickOnce takes up the folder path from where the user installed the setup.exe as the InstallFolder and looks there for updates.
I'm attempting to do a command line package deploy for our Windows Store Application.
My command line instructions are:
msbuild /m /p:Configuration=Debug /p:Platform=x86 /target:Build
I'm using VS2013 Professional with Windows 8.1
I get the following error:
C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v12.0\AppxPackage\Microsoft.AppXPackage.Targets(1224,9):
error APPX0002: Task 'GenerateAppxPackageRecipe' failed. Value cannot
be null.\r [C:\Path\Project.csproj]
C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v12.0\AppxPackage\Microsoft.AppXPackage.Targets(1224,9):
error APPX0002: Parameter name: source\r [C:\Path\Project.csproj]
How should I resolve this?
This error was resolved by using the correct version of msbuild.exe
On a clean build server with VS2013 installed, there are (at least) two copies of msbuild.exe installed. In our case the install locations were:
C:\Program Files (x86)\MSBuild\12.0\Bin\msbuild.exe
and
C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe
The one in the .Net Framework folder was the one that gave us the errors. Using the version installed in the Program Files folder resolved the issue.
It's impossible to help you without having the code which can reproduce the error. I suspect some property does not resolve correctly when building outside VS(eg VisualStudioVersion) and needs to be passed from command line. VS also uses msbuild to build your projects, so comparing build logs from VS and CMD should help you track down the problem.
I suggest, that you set visual studio's build output verbosity to diagnostic, clean solution, than build and capture the build log.
Then clean solution and build from command line with verbosity set to diagnostic and /fl switch(log to file, because diagnostic build log is way too long to analyse in console window).
Compare command-line output to VS output. Look for the differences. With diagnostic level of verbosity, chances are, you'll find out what's missing (I had similar issues with database projects failing to build from cmd due to VisualStudioVersion variable not being resolved correctly, so I passed it from command line).
NB: diagnostic log is very verbose which makes analysis hard: I'd start from detailed verbosity level.
I have deleted all files/folders from "project"/bin folder, cleaned the solution and rebuild with success !
For those facing the issue on hybrid app (corodova in my case), delete the build folder manually and re-build from VS.
Standard clean solution didn't do the job.
I have downloaded libsvm-3.17 package. Extracted the files. I go to 'tools' folder to try using grid.py to look for suitable c and g with the dataset provided in the package, i.e. heart_scale.
However, the following is what I get
Traceback (most recent call last):
File "C:...\Documents\libsvm-3.17\tools\grid.py", line 266, in run
if rate is None: raise RuntimeError('get no rate')
RuntimeError: get no rate
worker local quit.
Can someone help me figure out how to solve this problem.
Thank you very much.
You may need to scale the data in advance. I got the same problem and it sorted out after I scaled the data. Hope this help.
Firstly, if you are a newbie in libsvm, I would recommend you to try easy.py instead of grid.py. Secondly, before executing anything you have to compile libsvm, for compiling follow instructions given in README file (You must ensure nmake.exe, cl.exe, link.exe are in system path), here is what it says:
Windows binaries are in the directory `windows'. To build them via
Visual C++, use the following steps:
Open a DOS command box (or Visual Studio Command Prompt) and change to libsvm directory. If environment variables of VC++ have not
been set, type
"C:\Program Files\Microsoft Visual Studio 10.0\VC\bin\vcvars32.bat"
You may have to modify the above command according which version of
VC++ or where it is installed.
Type
nmake -f Makefile.win clean all
(optional) To build shared library libsvm.dll, type
nmake -f Makefile.win lib
Another way is to build them from Visual C++ environment. See details
in libsvm FAQ.
Once you have it installed you can start working with easy.py and grid.py.
This is what I tried on both a 64 bit and a 32 bit machine and grid.py works fine.
I have added the default install directories, if your installation directories are different modify accordingly.
Open command prompt and type
C:\Program Files (x86)\Microsoft Visual Studio xx\VC\bin\amd64\vcvars64.bat for 64 bit systems
OR C:\Program Files (x86)\Microsoft Visual Studio xx\VC\bin\vcvars32.bat for 32 bit systems.
Navigate to libsvm directory in the same command prompt and run
C:\Program Files (x86)\Microsoft Visual Studio xx\VC\bin\amd64\nmake.exe -f Makefile.win for 64 bit systems
OR C:\Program Files (x86)\Microsoft Visual Studio xx\VC\bin\nmake.exe -f Makefile.win for 32 bit systems
The binaries should be built successfully in the libsvm-3.xx\windows folder
Run grid.py with your options
Within grid.py the gnuplot.exe is usually set at tmp which never worked for me so I changed the gnuplot executable path in my grid.py to the following:
self.gnuplot_pathname = r'C:\\Program Files (x86)\\gnuplot\\bin\\pgnuplot.exe'
If you use the option -log2p to run grid.py, you will get output get no rate. With grid.py, you can't use -log2p option.(No matches for searching -log2p in grid.py)
You can use -log2p option in gridregression.py.
I've been trying to sign an MSI file in a post build event with the following code
signtool sign /t http://timestamp.verisign.com/scripts/timestamp.dll /f "E:\Products\Tools\DigitalId\Certificate.pfx" /p 1501ocbc /d "Server" "E:\Products\Setup\Server_Setup\ServerSetup\bin\Release\en-US\ServerSetup.msi"
This will sign OK with the Visual Studio command prompt and similar code works for C++ projects. However, when building the setup and signing the code with post build events, I get a code error, 9009. After much debugging I have come to the conclusion that WiX is using the ordinary command prompt. How do I get cmd.exe in WiX to open with Visual Studio tools?
Or is there another way to sign my packages?
You could define the event like this:
"%programw6432%\microsoft sdks\windows\v7.1\bin\signtool.exe" sign /t etc..
Note: you need to adapt the path to your install (program files, Windows SDK version, etc.), or you could also define your own environment variable.
It looks like there is a built-in way of signing MSI files which seems to work correctly with SignTool: Insignia.
Register the certificate and use the /sha1 hashkey - just to be sure the certificate is good (check browser-internetoptions/content/certificate)
SignTool path - make it explicit as Simon Mourier suggested or put signtool.exe in an accesible path
Choosing postbuild operation - you should sign the MSI file after you've completed all operations upon the MSI file. Any action upon the MSI (INSERT/UPDATE Property) will undo the signing.
I'm trying to get a Lightswitch Project into Teamcity and have tried the following runner types:
Visual Studio (sln)
MSBuild
Command line (ran MSBuild through the command line)
All 3 runner types gave me the same error when building the Lightswitch solution:
The "UnpackExtensionsToProjectDir" task failed unexpectedly. System.NullReferenceException: Object reference not set to an instance of an object.
Lightswitch has already been installed on the server. Have tried building the solution manually using Visual Studio on the server and it builds fine. Have also tried building the solution via the command line (using MSBuild) and it builds fine too.
Would like to ask if somebody was able to get Lightswitch building nicely on TeamCity. Cheers.
This is how you build via the Command line (using TeamCity)
Pre-requisites)
First make sure you have not checked in the extensions directory, this can cause issues when building.
Check that you have installed any visual studio extensions on the build machine .ie ExtensionsMadeEasy. You can test this by opening the solution in visual studio on the build machine and trying to do a build.
Lastly, in TeamCity do not use the msbuild task, use command line to call msbuild.
Step 1)
msbuild.exe mylightswitchproject.lsproj /p:OutDir=C:\test\stuff\;configuration=Release
Step 2)
Create a bat file to copy your output to the correct folder structure.
robocopy C:\test\stuff\bin C:\test\localrelease\bin *.* /MIR
robocopy C:\test\stuff\Resources C:\test\localrelease\Resources *.* /MIR
robocopy C:\test\stuff\Web C:\test\localrelease\Web *.* /MIR
robocopy C:\test\stuff\ C:\test\localrelease\ ClientAccessPolicy.xml
robocopy C:\test\stuff\ C:\test\localrelease\ default.htm
robocopy C:\test\stuff\ C:\test\localrelease\ Home.aspx
robocopy C:\test\stuff\ C:\test\localrelease\ Login.aspx
robocopy C:\test\stuff\ C:\test\localrelease\ LogOff.aspx
robocopy C:\test\stuff\ C:\test\localrelease\ Silverlight.js
robocopy C:\test\stuff\ C:\test\localrelease\ web.config
You can now take this folder and release it to the next environment.
Finally, if you want to create a web deployment package, out the box visual studio 2010 does not support this. However, you can copy this into an existing website then "Export" your application into a package that is then ready for web deployment via powershell.
The previous answers didn't work for us but Yaegor's answer provided some direction.
The issue we had was extensions are installed at the user level, not the system level. This meant the MSBuild process could not find the required extensions.
Our solution was to use a user account on the build server, log into account, setup VS.NET such that the LS project builds, and then switch the TeamCity agent service to use the new user account.
With this we were able to use the Solution runner (which is preferable to the CLI runner since it provides better logging and reporting).
For not Lightswitch-specific part: If command line works from console, but fails in TeamCity, most probably the issue is in the user or running as a service. You might try running TeamCity agent with the same environment.
When command line works you can then try MSBuild and Solution runners.
I ran into the same error when trying to set up an automated build for a lightswitch application using bamboo. Turned out to be the version of msbuild being called. If the 64bit version is called (from bamboo or the command line) I get the error:
UnpackExtensionsToProjectDir" task failed unexpectedly.
Switching to the 32bit version of msbuild fixes the problem.
32bit Path: 'C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe'
64bit Path: 'C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe'