I'm trying to publish my application with the publish tool from Visual Studio.
When I build the app, the NativeBinaries directory with libgit2 for x86 and amd64 is well copied in the build directory bin/Release, so the application run perfectly in my dev environment.
The problem is, with the Publish Wizard to create a ClickOnce Application, the native binaries are not integrated, so I have an error on another computer :
System.DllNotFoundException: Impossible de charger la DLL 'git2-e0902fb': Le module spécifié est introuvable. (Exception de HRESULT : 0x8007007E)
à LibGit2Sharp.Core.NativeMethods.git_libgit2_init()
à LibGit2Sharp.Core.NativeMethods.LibraryLifetimeObject..ctor()
à LibGit2Sharp.Core.NativeMethods..cctor()
LibGit2Sharp.dll.deploy is correctly copied in the Application Files directory at the end of the publish process.
I tried many solutions I found, like to create a link with the .dll files or using a post or pre-build event.
IDE : Visual Studio 2013 Express for Windows Desktop.
LibGit2Sharp.0.21.0.176 is installed with NuGet.
The reason the native binary files aren't included in the ClickOnce manifest is that their Build Action is set to None by the LibGit2Sharp.NativeBinaries NuGet package. The Publish Wizard only includes files that are set to Content.
You could link the NativeBinaries folder from the NuGet package into your project and set the Build Action to Content, but you'd need to maintain that manually any time the package updates.
Another option would be to manually add the files to the ClickOnce manifest using the procedure described here.
However, the best option is probably to avoid using ClickOnce in the first place. I recommend taking a look at Squirrel instead.
Related
I just started using TFS not to long ago and I ran into a slight issue. I have a class library project called EplanInterface.Addin. This class library project is used as a way to load functionality into a 3rd party program through their API. All of this is working fine but the issue comes into play here:
The Issue:
So the problem I am running into is that this Addin library is not referenced by any other projects but still needs to be output to my Drop folder within my TFS build. Typically to load the Addin into the 3rd party program I would copy the debug/release folder to the server and select/load the dll accordingly. My TFS build does not seem to grab the anything from the Addin though?
App.Config
Along with that I am using SlowCheetah to try and transform my app.config file resources correctly. Whatever solution provided I need to also figure out how to select a transform when doing the build configuration and output the dlls with the correct build configuration config file.
Build Definition
My build definition is the basic asp.net template they provide which works great for my web api and MVC projects. I guess I am unsure how to force it to also build the addin / output the dll files for my addin to reference?
Other Info:
TFS Version: 16.122.27102.1
Addin Project .Net Framework 4.5.2
Slow Cheetah Version: 3.2.26
You can simply add another build task to your pipeline to build the specific addin project and then have it output to the artifacts directory (as the default "Build Solution" task should already be doing).
The other option is to edit the solution file in Visual Studio and include the addin as a project dependency. You may still need to manage the binary output though.
I try to configure Hudson (3.1.0) to build Delphi XE3 project (MSBuild).
Batch for build:
call "C:\Program Files (x86)\Embarcadero\RAD Studio\10.0\bin\rsvars.bat"
msbuild "X:\Tests\DelphiTest\Project1Test.dproj" /t:Build /v:minimal /p:config="Debug"
Run this batch in command line (cmd.exe) - build correct.
When I put this batch into Hudson build step faild with errors from delphi compiler:
[..]
C:\Program Files (x86)\Embarcadero\RAD Studio\10.0\bin\CodeGear.Common.Targets : warning : Expected configuration file missing - C:\Windows\system32\config\systemprofile\AppData\Roaming\Embarcadero\BDS\10.0\EnvOptions.proj
_PasCoreCompile:
Embarcadero Delphi for Win32 compiler version 24.0
Copyright (c) 1983,2012 Embarcadero Technologies, Inc.
C:\Program Files (x86)\Embarcadero\RAD Studio\10.0\Bin\CodeGear.Delphi.Targets(172,5): error E1026: File not found: 'Controls.res'
[..]
In fact I don't have missing file in this location. But I've found it in
C:\Users\<username>\AppData\Roaming\Embarcadero\BDS\10.0
So I try do dummy think like copy existing dir to missing location but it doesn't work.
I'm using: Delphi XE3 Enterprise, Win 7 Ultimate (x64)
Thanks for help.
this usually happens the first time you run MSBUILD or DCC32 on a machine which has never had the IDE gui open (bds.exe) and which has passed the mandatory startup environment configuration tasks that happen inside BDS.exe.
If you log in on Hudson or Jenkins as a Windows service using an account that has never been used for Windows logins, has never run BDS.exe, you will get this issue. The MSBUILD utility from Microsoft must invoke DCC32, which is licensed commercial software, and the Delphi command line compilation licensing and environment configuration requires that you have run the IDE as the account, and that your jenkins build account and computer is licensed properly.
Solution:
Either change Jenkins or Hudson to log in as an account that has a license to run Delphi, and has run Delphi at least once.
If you can't change the server login, then log in interactively (via remote desktop) using the account that Jenkins/Hudson is using, and configure Delphi (Rad Studio) so it runs fine from that account.
Update 2015: I am now running into a whole new class of problems related to Group Managed Service Accounts. They were working with Delphi XE8, but I am not able to get a GMSA account to work with Delphi 10 Seattle. I'll update this answer if I ever do figure out a way, but for now, I recommend conventional service accounts, not GMSAs, for Delphi continuous integration with Jenkins or Continua, or others. Also check Delphi.wikia.com for more tips: http://delphi.wikia.com/wiki/Setting_up_a_Delphi_Build_Machine
We recently ran in a similar kind of problem. We are trying to compile our projects on an jenkins. We simplified the "build" script to the following 2 lines
call "[....]Embarcadero\Studio\18.0\bin\rsvars.bat"
MSBuild.exe /p:config=Release /target:Rebuild Project2.dproj
This is building the project successful.
But when we switch to /p:config=debug the build fails with the known errors about missing *.res files. We looked up in the delphi lib/win32/ directory and realized that there are *.res files in the release folder but not in the debug folder. We now further modified the msbuild command to this:
MSBuild.exe /p:config=Release /target:Rebuild /p:ResourcePath="%BDS%\lib\win32\release" Project2.dproj
And this is compiling just fine. So apparently the compiling in debug mode lacks the path to the delphi sources (which are included in several subfolders in %BDS%\source\
So as a workaround we can compile debug builds using jenkins and simply giving delphi the *.res files from its release folder. But that can only be an intermediate solution.
Maybe this information helps someone to find a final solution which is not "Adding all subfolders of %BDS%\source into the search path" ;-)
I have a website, a windows service, and some shared class libraries in a single Visual Studio solution. I use Octopack on both the website and windows service, and on my machine these builds work as expected.
When using the TFS Build Server, the website nuget package is generated as expected, but the windows service nuget package contains all files from the website, as well as the service. E.g. it includes the _PublishedWebsites folder as well.
This is because TFS uses a single location to build projects.
What is the best way around this?
I know this question has since been closed, but I cam across this issue and solved it in a different way.
My solution is compromised of a number of websites and windows services and had the same issue of the OctoPack created nuget packages including all the solution assemblies from the 'pooled' output folder when building with Team Build. The reason the nuget packages get all the assemblies is OctoPack uses the outdir msbuild argument as the location to include assemblies from.
The way I got around it was to use the msbuild argument GenerateProjectSpecificOutputFolder=true. This instructs Team build to create a folder for each project in your output folder in the same way Visual Studio uses the bin folders under each project when building locally.
My build definition msbuild arguments looks like:
/p:GenerateProjectSpecificOutputFolder=true;RunOctoPack=true;OctoPackPublishPackageToFileShare=\\<NugetServer>
I currently just push the packages onto a shared folder but the OctoPackPublishPackageToHttp and OctoPackPublishApiKey parameters can also be used.
The benefit of this solution over the one above is you don't need to specify the files to include the nuget package.
Hope this helps someone.
I ended up using this nuget package to ensure the console app built to a seperate directory on the TFS server.
https://nuget.org/packages/PublishedApplications/2.1.0.0
I then had to specify in the nuspec file, which files should be included for the console app. e.g
This works and I can now deploy using Octopus deploy.
The downside of this apporach is that the PublishedApplications build only works on the TFS build server, so I can't build the project locally in release mode. Still looking on how to overcome this.
The packages created by a TFS 2010 Build only contain our Sources, not the binaries. When this is (automatically) deployed to IIS, the site does not run because it is missing DLLs that are created during the build process.
We have a Web Project created in VS2010. If I select "Build Deployment Package" from a right click in VS we get a zip file in the obj\Release\Package folder that contains the fully build site.
However, if ask our TFS build process to create the package by adding "/p:CreatePackageOnPublish=true /p:DeployOnBuild=true" to the MSBuild arguments (as advised in amongst other places here) we get an zip file in _PublishedWebsites\_Package\.zip that only contains the sources.
My best guess is that the CopyAllFilesToSingleFolderForPackage is picking up the files from the wrong place.
I notice a similar issue asked here - TFS 2010 and creating a package - although his workaround in not appropriate in many cases, I'd guess.
My concern is that this is using a built-in, but poorly documented feature of MSBuild/TFS so when it doesn't work you're a little in the wilderness.
It seems that deployOnBuild runs some "package"-like target on each of the projects. If you have built the projects into a separate directory (which the default TFS 2010 build does by default) the packaging won't pick up the compiled files.
One solution is to get rid of the custom output folder for the MSBuild Command within the TFS build workflow. This will cause the compiled files to be located in-situ and be included in the package.
Now the rest of the TFS workflow is require some changes because it'll be expecting to transfer the files from the output directory, and they won't be there.
My .sln file has a website (and a few other web applications). The web applications get published to the _PublishedWebsites directory, but not the website. I am not using a custom build configuration. This happens in both Release and Debug mode.
Any ideas?
During the TFS build it checks the project file for Imports which it uses to define the build requirements. The Visual Studio 2010 import for web projects ($(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets) does not contain a definition for the outputting to *_PublishWebsites* as the Visual Studio 2009 one ($(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets) had.
To solve this you need to edit the web application target file on the build server to enable this functionality.
Additional information and assistance can be found at
http://social.msdn.microsoft.com/Forums/zh/tfsbuild/thread/0bd3b8de-0397-41f1-b43a-5ccdd04f9436
http://social.msdn.microsoft.com/Forums/en-US/tfsbuild/thread/559a53e1-2eeb-48e9-a95f-400154b3333f