How to Publish an WinForms into 1 executable? - c#

I wanted to Publish a WinForm (.Net framework) as an executable (JUST 1 File). I had tested different ways of doing it.
I had tried
dotnet publish -r win-x64 /p:PublishSingleFile=true /p:IncludeNativeLibrariesForSelfExtract=true --output ../result
Error: C:\Program
Files\dotnet\sdk\5.0.302\Microsoft.Common.CurrentVersion.targets(3746,5):
error MSB4062: The "Microsoft.Build.Tasks.AL" task could not be loaded
from the assembly Microsoft.Build.Tasks.Core, Version=15.1.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a. Confirm that the
declaration is correct, that the assembly and all its
dependencies are available, and that the task contains a public class
that implements Microsoft.Build.Framework.ITask.
[C:\RPIC\PICDashboard\PICDashboard\PICDashboard\PICDashboard.csproj]
and
msbuild /t:Publish /p:PublishSingleFile=True /p:IncludeNativeLibrariesForSelfExtract=True /p:SelfContained=True /p:Configuration=Release /p:Platform="Any CPU" /p:RuntimeIdentifier=win-x64 /p:OutputPath=../result
msbuild works without error but it produces many files as what's in the Debug and Release folder. It also give me a warning
C:\RPIC\PICDashboard\PICDashboard\PICDashboardSetup\PICDashboardSetup.vdproj.metaproj : warning MSB4078: The project file "PICDashboardSet
up\PICDashboardSetup.vdproj" is not supported by MSBuild and cannot be built.
I had also tried
dotnet msbuild -target:Publish -property:PublishSingleFile=True -property:IncludeNativeLibrariesForSelfExtract=True -property:SelfContained=True -property:Configuration=Release -property:RuntimeIdentifier=win-x64 -property:Platform="Any CPU" -property:OutDir=../result
Error: C:\Program
Files\dotnet\sdk\5.0.302\Microsoft.Common.CurrentVersion.targets(3746,5):
error MSB4062: The "Microsoft.Build.Tasks.AL" task could not be loaded
from the assembly Microsoft.Build.Tasks.Core, Version=15.1.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a. Confirm that the
declaration is correct, that the assembly and all its
dependencies are available, and that the task contains a public class
that implements Microsoft.Build.Framework.ITask.
[C:\RPIC\PICDashboard\PICDashboard\PICDashboard\PICDashboard.csproj]
Is there any way that allows me to publish WinForms as a single exe?

"Any way" - yes, though I can't say "always"/"for all" applications and its dependencies.
Also, the following is done in Visual Studio (not dotnet cli - I haven't tried) with a trivial "Hello World" Windows Forms app (no external dependencies)
In your Application Build properties -> Release Configuration set Debugging information to None
In your Publish Settings
Result (in the bin\Release\net5.0-windows\publish\ folder set above):
Running an awesome app :)
Hth...

Which IDE version are u using. You cam choose produce single file in publish setting (1click publish method for vs2019)

Related

Azure devops Cant connect Nuget Restore and VSBuild for Nuget Packages

I have a very basic build pipeline so far
# ASP.NET
# Build and test ASP.NET projects.
# Add steps that publish symbols, save build artifacts, deploy, and more:
# https://learn.microsoft.com/azure/devops/pipelines/apps/aspnet/build-aspnet-4
trigger:
- testing-build-yml-1
pool:
vmImage: 'windows-latest'
variables:
solution: '**/*.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Release'
steps:
- task: NuGetToolInstaller#1
- task: NuGetCommand#2
inputs:
restoreSolution: '$(solution)'
# packagesDirectory: '..\packages'
restoreDirectory: '..\new_packages'
- task: VSBuild#1
inputs:
solution: '$(solution)'
#msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactStagingDirectory)"'
msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactStagingDirectory)" /p:ReferencePath="d:\a\1\new_packages"'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
I am trying to the Nuget Restore task to get packages restored to ..\new_packages directory and subsequently hoping that the VSBuild Task will get them from there and build the solution.
The Nuget Restore executes the following command (all in one line)
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\bin\msbuild.exe
"C:\Users\VssAdministrator\AppData\Local\Temp\NuGetScratch\jgtjjpe0.nac.nugetinputs.targets"
/t:GenerateRestoreGraphFile
/nologo
/nr:false
/v:q
/p:NuGetRestoreTargets="C:\Users\VssAdministrator\AppData\Local\Temp\NuGetScratch\whba0xm4.c0f.nugetrestore.targets"
/p:RestoreUseCustomAfterTargets="True" /p:RestoreTaskAssemblyFile="C:\hostedtoolcache\windows\NuGet\5.4.0\x64\nuget.exe"
/p:RestoreSolutionDirectory="D:\a\1\s\\"
/p:RestoreConfigFile="D:\a\1\Nuget\tempNuGet_105.config"
/p:RestorePackagesPath="..\new_packages"
/p:SolutionDir="D:\a\1\s\\"
/p:SolutionName="XYZ"
Then VSBuild Task runs msbuild (all in one line)
##[command]"C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\msbuild.exe"
"D:\a\1\s\XYZ.sln"
/nologo
/nr:false
/dl:CentralLogger,
"D:\a\_tasks\VSBuild_71a9a2d3-a98a-4caa-96ab-affca411ecda\1.161.2\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll";
"RootDetailId=e5869970-8e7b-4a06-a8fd-f0662f639a6d|SolutionDir=D:\a\1\s"*ForwardingLogger,"D:\a\_tasks\VSBuild_71a9a2d3-a98a-4caa-96ab-affca411ecda\1.161.2\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll"
/p:DeployOnBuild=true
/p:WebPublishMethod=Package
/p:PackageAsSingleFile=true
/p:SkipInvalidConfigurations=true
/p:PackageLocation="D:\a\1\a"
/p:ReferencePath="d:\a\1\new_packages"
/p:platform="Any CPU"
/p:configuration="Release"
/p:VisualStudioVersion="16.0"
/p:_MSDeployUserAgent="VSTS_607486bc-2d64-463d-9a7f-0cf06fe82263_build_16_0"
The solution looks at the appropriate directory as specified in the /p:ReferencePath="d:\a\1\new_packages.
But it still can't find any dlls for the Nuget packages and ultimately the build fails.
Building the projects in this solution one at a time. To enable parallel build, please add the "-m" switch.
Build started 1/9/2020 10:11:18 PM.
Project "D:\a\1\s\XYZ.sln" on node 1 (default targets).
ValidateSolutionConfiguration:
Building solution configuration "Release|Any CPU".
Project "D:\a\1\s\XYZ.sln" (1) is building "D:\a\1\s\ServiceLayer\InputOutputServiceLayer.csproj" (2) on node 1 (default targets).
PrepareForBuild:
Creating directory "bin\Release\".
Creating directory "obj\Release\".
ResolveAssemblyReferences:
Primary reference "EPPlus, Version=4.5.3.2, Culture=neutral, PublicKeyToken=ea159fdaa78159a1, processorArchitecture=MSIL".
##[warning]C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(2106,5): Warning MSB3245: Could not resolve this reference. Could not locate the assembly "EPPlus, Version=4.5.3.2, Culture=neutral, PublicKeyToken=ea159fdaa78159a1, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(2106,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "EPPlus, Version=4.5.3.2, Culture=neutral, PublicKeyToken=ea159fdaa78159a1, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. [D:\a\1\s\ServiceLayer\InputOutputServiceLayer.csproj]
For SearchPath "d:\a\1\new_packages".
Considered "d:\a\1\new_packages\EPPlus.winmd", but it didn't exist.
Considered "d:\a\1\new_packages\EPPlus.dll", but it didn't exist.
Considered "d:\a\1\new_packages\EPPlus.exe", but it didn't exist.
For SearchPath "{HintPathFromItem}".
Considered "D:\a\1\s\packages\EPPlus.4.5.3.2\lib\net40\EPPlus.dll", but it didn't exist.
Technically, I know we're not supposed to hardcode a /p:ReferencePath=.. do this but I'm just trying to get it to work.
Without that VSBuild Task seems to have no idea where to even look.
It looks at
ResolveAssemblyReferences:
Primary reference "EPPlus, Version=4.5.3.2, Culture=neutral, PublicKeyToken=ea159fdaa78159a1, processorArchitecture=MSIL".
##[warning]C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(2106,5): Warning MSB3245: Could not resolve this reference. Could not locate the assembly "EPPlus, Version=4.5.3.2, Culture=neutral, PublicKeyToken=ea159fdaa78159a1, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(2106,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "EPPlus, Version=4.5.3.2, Culture=neutral, PublicKeyToken=ea159fdaa78159a1, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. [d:\a\1\s\ServiceLayer\InputOutputServiceLayer.csproj]
For SearchPath "..\d:\a\1\a".
Considered "..\d:\a\1\a\EPPlus.winmd", but it didn't exist.
Considered "..\d:\a\1\a\EPPlus.dll", but it didn't exist.
Considered "..\d:\a\1\a\EPPlus.exe", but it didn't exist.
For SearchPath "{HintPathFromItem}".
Considered "d:\a\1\s\packages\EPPlus.4.5.3.2\lib\net40\EPPlus.dll", but it didn't exist.
For SearchPath "{TargetFrameworkDirectory}".
Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\EPPlus.winmd", but it didn't exist.
There is a similar question using the old way of using the pipeline
MsBuild does not find restored NuGet-Packages on Visual Studio Online
Their solution (though hacky) doesn't work for me either.
If I remove the EPPlus package, the next package Entity Framework will produce the same errors.
If I remove Entity Framework the next package will produce the same errors.
I'm just trying to find a real solution for this which doesn't involve these hardcoding hacks (..and works, obviously)
EDIT:
Working, with quirks thanks to Leo Liu-MSFT.
My answer is below that one.
Azure devops Cant connect Nuget Restore and VSBuild for Nuget Packages
I am afraid you could not make it work unless you modify the HintPath in your project file.
When you change the nuget packages restored to ..\new_packages directory, after restore, the package in the new directory should have following structural levels:
d:\a\1\new_packages\EPPlus.4.5.3.2\lib\net40\EPPlus.dll
The dll file is stored in your new directory in the form of a nuget package, rather than directly in the new directory.
So, when you specify the /p:ReferencePath="d:\a\1\new_packages" during building the project, VS will find the dll file directly from the ReferencePath. That the reason why you get the error message is:
Considered "d:\a\1\new_packages\EPPlus.dll"
Actually, the dll path should be d:\a\1\new_packages\EPPlus.4.5.3.2\lib\net40. Since this path is related to both the name and version of the package, we could not use one parameter to specify the path of multiple dlls.
In this case, we have to modify the HintPath in the project file.
The correct process is that change the repositoryPath in the nuget.config file to change the nuget package directory on your local:
Is it possible to change the location of packages for NuGet?
then use command line Update-Package -reinstall in the Package Manager Console to force reinstall the package references into project on your local, it will update the HintPath for all packages, then submit the changes to the source control. Then we could use the Nuget Restore task to get packages restored to ..\new_packages directory
Hope this helps.
I got it to work but with a few quirks (and features?) and few pending questions.
Please see /users/7460777/leo-liu-msft above to get some context as to why some of these steps are taken.
As Leo mentioned this has to do with the HintPath not being updated properly in the projects that use packages.config
To avoid this issue altogether,
migrate as many projects as possible to the <PackageReference /> instead of using packages.config. To do this, right click on the References inside each project, there should be an option to do so.
Some projects (E.g -> in my case, my asp.net (.net Framework) MVC Web Client) can't be migrated.
(..I'll add more details i found on this later)
UPDATE:
(https://devblogs.microsoft.com/nuget/migrate-packages-config-to-package-reference/)
(https://github.com/NuGet/Home/issues/5877)
Next Steps:--
1) On the top level folder where I have the .sln file, I created the following nuget.configfile.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<config>
<add key="repositoryPath" value=".\packages" />
</config>
</configuration>
Since my packages directory is here.
2) My updated build.ymlis below.
# ASP.NET
# Build and test ASP.NET projects.
# Add steps that publish symbols, save build artifacts, deploy, and more:
# https://learn.microsoft.com/azure/devops/pipelines/apps/aspnet/build-aspnet-4
trigger:
- testing-build-yml
pool:
vmImage: 'windows-latest'
variables:
solution: '**/*.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Release'
steps:
- task: NuGetToolInstaller#1
- task: NuGetCommand#2
inputs:
restoreSolution: '$(solution)'
packagesdirectory: '.\packages'
- task: VSBuild#1
inputs:
solution: '$(solution)'
msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactStagingDirectory)"'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
3) The following step caused everything to work, but Im still unsure why exactly.
I deleted everything inside the packages folder and basically just pushed those deletions upstream.
Nuget restore Task did a restore and the VSBuild task succeeded.
Things I'm still unsure of --
1) Why is a temporary Nuget.config file created even though I clearly said where it exists?
Saving NuGet.config to a temporary config file.
[command]C:\hostedtoolcache\windows\NuGet\5.4.0\x64\nuget.exe sources Add -NonInteractive -Name NuGetOrg -Source https://api.nuget.org/v3/index.json -ConfigFile d:\a\1\Nuget\tempNuGet_140.config
Package source with Name: NuGetOrg added successfully.
[command]C:\hostedtoolcache\windows\NuGet\5.4.0\x64\nuget.exe restore d:\a\1\s\XYZ.sln -PackagesDirectory .\packages -Verbosity Detailed -NonInteractive -ConfigFile d:\a\1\Nuget\tempNuGet_140.config
NuGet Version: 5.4.0.6315
MSBuild auto-detection: using msbuild version '16.4.0.56107' from 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\bin'. Use option -MSBuildVersion to force nuget to use a specific version of MSBuild.
MSBuild P2P timeout [ms]: 120000
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\bin\msbuild.exe
"C:\Users\VssAdministrator\AppData\Local\Temp\NuGetScratch\0eie04ka.4ch.nugetinputs.targets" /t:GenerateRestoreGraphFile /nologo /nr:false /v:q /p:NuGetRestoreTargets="C:\Users\VssAdministrator\AppData\Local\Temp\NuGetScratch\y3ui4hhz.gfr.nugetrestore.targets" /p:RestoreUseCustomAfterTargets="True" /p:RestoreTaskAssemblyFile="C:\hostedtoolcache\windows\NuGet\5.4.0\x64\nuget.exe" /p:RestoreSolutionDirectory="d:\a\1\s\\" /p:RestoreConfigFile="d:\a\1\Nuget\tempNuGet_140.config" /p:RestorePackagesPath=".\packages" /p:SolutionDir="d:\a\1\s\\" /p:SolutionName="XYZ"
2) Why does deleting packages make it work while committing the packages make it unable to find any dll files even though it looks at the correct places?
Primary reference "NLog, Version=4.0.0.0, Culture=neutral, PublicKeyToken=5120e14c03d0593c, processorArchitecture=MSIL".
##[warning]C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(2106,5): Warning MSB3245: Could not resolve this reference. Could not locate the assembly "NLog, Version=4.0.0.0, Culture=neutral, PublicKeyToken=5120e14c03d0593c, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(2106,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "NLog, Version=4.0.0.0, Culture=neutral, PublicKeyToken=5120e14c03d0593c, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. [D:\a\1\s\XYZ_WebClient\XYZ_WebClient.csproj]
For SearchPath "{HintPathFromItem}".
Considered "D:\a\1\s\packages\NLog.4.6.7\lib\net45\NLog.dll", but it didn't exist.
For SearchPath "{TargetFrameworkDirectory}".
Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\NLog.winmd", but it didn't exist.
Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\NLog.dll", but it didn't exist.
Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\NLog.exe", but it didn't exist.
Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\Facades\NLog.winmd", but it didn't exist.
Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\Facades\NLog.dll", but it didn't exist.
Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\Facades\NLog.exe", but it didn't exist.

"dotnet build" command fails with error MSB6006: "csc.exe" exited with code 1

I'm trying to get a Xamarin Forms solution to build from the command line as part of a build script using the command dotnet build <solution.sln>. Most of the projects in the solution build; however, two projects fail with this error message: error MSB6006: "csc.exe" exited with code 1.(on Ubuntu) and error MSB6006: "csc.exe" exited with code 8. (on Mac).
I have running Ubuntu 18.04 (using Windows subsystem for Linux) and MacOS 10.13.6 on separate machines.
I have also tried to run dotnet build <solution.sln> from the windows command line which prints out this error message instead:
error MSB4062: The "XamarinLive.Build.XamarinLiveTask" task could not be loaded from the assembly C:\Users\Jason.nuget\packages\livexaml\2.1.22\build\XamarinLive.Build.dll. Could not load file or assembly 'Microsoft.Build.Utilities.v4.0, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
However, the solution works and builds fine from within VS2017 (Version 15.9.7). I've tried scouring the binary log that is generated but I can't make much sense of it and there doesn't seem to be any obvious errors (on Ubuntu & Mac). Could the windows error message be related in some way?
The projects that are failing target netstandard 2.0 (The same as the projects that do build). The version returned by dotnet --version on all 3 environments is 2.1.504.
Any help would be greatly appreciated.
You need to use msbuild.exe instead of dotnet
build
for this situation.
msbuild.exe runs on full framework while dotnet buildruns on .NET Core, and most of the build tasks don't support that.
When you build them in VS,it actually calls the msbuild.exe to build the solution.So you can build it well by developer command prompt since it also calls the msbuild.exe.
For vs2017, you can find it in C:\Program Files (x86)\Microsoft Visual Studio\2017\Edition\MSBuild\15.0\Bin.
More details see Martin's answer from this similar issue. Thanks to his detailed description!

Generation of the sonar-properties file failed. Unable to complete SonarQube analysis

Application Stack
Jenkins
.NET 4.7
SonarQube 7.4
Bitbucket (Source control)
VS 2015 Update 3
VsTest to execute UnitTest
Path of Msbuid in Global Tools Configuration is
C:\Program Files (x86)\MSBuild\14.0\Bin\Msbuild.exe
Also tried with C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Msbuild.exe
We have created sample project and configured all in one server.
We can see multiple kind of errors in log files like
Generation of the sonar-properties file failed. Unable to complete SonarQube analysis.
WARNING: File 'C:\Program Files (x86)\Jenkins\workspace\CICD\UnitTestProject1\Properties\AssemblyInfo.cs' is not located under the root directory 'C:\Program Files (x86)\Jenkins\workspace\CICD.sonarqube\out' and will not be analyzed
No analysable projects were found. SonarQube analysis will not be performed
This only comes when i use msbuild from "Program files" An instance of analyzer SonarAnalyzer.Rules.CSharp.FieldsShouldNotBePublic cannot be created from C:\Users\manish.joisar\AppData\Local\Temp.sonarqube\resources\0\SonarAnalyzer.CSharp.dll : Could not load file or assembly 'Microsoft.CodeAnalysis, Version=1.3.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies
I can see message with build succeeded.
I can also see successful test run message
Total tests: 1. Passed: 1. Failed: 0. Skipped: 0.
Test Run Successful.
Sonar configuration is done in build configuration under "Execute Sonar scanner" step
I am not sure what is missing here, wrong configuration, wrong msbuild ??
I suppose you have gone through this documentation https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner+for+MSBuild for getting all the dependencies information and the command required to run the analysis.
I was getting some of the error mentioned above when i was trying to analyse c# files but i require more information to understand your case so please provide the o/p of each steps mentioned below:
SonarScanner.MSBuild.exe begin /k:"project-key"
MSBuild.exe <path to solution.sln> /t:Rebuild
SonarScanner.MSBuild.exe end
If you are running through jenkins MSBuild plugin, then please provide the verbose output of the same.
I solved all above issues with below configuration in Jenkins
SonarQube configuration
Jenkin Global tool configuration
Freestyle project configuration

Hadoop Streaming, C#, & Azure with External Libraries

I'm using Hadoop Streaming to run a mapreduce job in C# on a Linux cluster in Azure. However, I need to use the MathNet.Numerics library. I grabbed the dll using the NuGet package manager then included the dll as a reference file and in a lib folder as well as ensured that the build action is set to: Embedded Resource.
Whenever I try to run the following command:
hadoop jar ./hadoop-streaming-2.6.0.jar -input wasb:///CSV/ -output
wasb:///Output/reducer1.txt -file ./Mapper.exe -mapper Mapper.exe
-file ./Reducer.exe -reducer Reducer.exe
I get the following error in my output file:
System.IO.FileNotFoundException: Could not load file or assembly
'MathNet.Numerics, Version=3.11.0.0, Culture=neutral, PublicKeyToken=null'
or one of its dependencies.
File name: 'MathNet.Numerics, Version=3.11.0.0, Culture=neutral, PublicKeyToken=null'
I've also tried to copy to MathNet.Numerics.dll to the cluster and include the file with a tag in the initial command:
hadoop jar ./hadoop-streaming-2.6.0.jar -input wasb:///CSV/ -output
wasb:///Output/reducer1.txt -file ./Mapper.exe -mapper Mapper.exe
-file ./Reducer.exe -reducer Reducer.exe -file ./MathNet.Numerics.dll
but had the same result.
On windows in VS 2014+
-Right click on "references", in the solution explorer.
-Select: Manage NuGet Packages
Click Browse, then type in the library your trying to install, it should grab everything you need including dependencies.
On Linux with Mono:
-https://docs.nuget.org/contribute/setting-up-the-nuget-development-environment
-Scroll down to the Linux install instructions
I have not used NuGet on Mono, but I assume it should work exactly the same way. I would at least try it to see if you're simply missing a dependency somewhere, as it should auto-magically get them for you.

Can't build NUnit testing project under Mono and Linux

I have a complex solution (developed under Windows, deployed under GNU\Linux) with a number of unit-testing projects, using NUnit 2.9.3.
Here's a reference from project:
<Reference Include="nunit.framework, Version=2.9.3.0, Culture=neutral, PublicKeyToken=96d09a1eb7f44a77, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\..\..\..\..\Program Files\NUnit 2.9.3\bin\net-4.0\nunit.framework.dll</HintPath>
</Reference>
I downloaded and built NUnit 2.9.3 from source:
$ xbuild solutions/MonoDevelop/NUnit.Framework.sln /p:Configuration=Release
and installed into GAC:
$ gacutil /i solutions/MonoDevelop/bin/Release/nunit.framework.dll
$ gacutil /l nunit.framework
The following assemblies are installed into the GAC:
nunit.framework, Version=2.9.3.0, Culture=neutral, PublicKeyToken=96d09a1eb7f44a77
Number of items = 1
and deleted local mono nunit installation:
$ rm /usr/lib/mono/2.0/nunit*
$ rm /usr/lib/mono/4.0/nunit*
but when I try to build my solution:
$ xbuild MySolution.sln | grep error
: error CS0006: Metadata file `/usr/lib/mono/2.0/nunit.framework.dll' could not be found
What do I wrong?
Build tools do not normally resolve assemblies from the GAC (except possibly as a last resort). On .NET they they "assembly folders" registered in the registry. On Mono they use "pkgconfig". You may have removed the nunit assemblies but you did not remove or fix the pkgconfig ("pc") file that tells xbuild and MonoDevelop where to find the dll.
This kind of stuff is why it's a bad idea to alter things installed by packages. You should either uninstall the package properly, or use the appropriate environment variables to override packaged stuff.
In this case, I would suggest you create a pc file for your new nunit assemblies, and put it into the /usr/local/lib/pkgconfig directory (/usr/local is the prefix for installing stuff you build from source), or put it somewhere else and have that somewhere else included in the PKG_CONFIG_PATH environment variable.
See also:
The MonoDevelop FAQ entry
And for some general background on configuring Mono environments, see:
Parallel Mono Environments
How not to break Mono installations
What I will try is to copy the NUnit 2.9.3 to my source file folder such as (solution folder)\lib. Then add this reference locally and make sure the tag matches this local path.
When that is configured, I think xbuild should use this local copy directly instead of reading GAC or other preconfigured paths. If not, I will report a bug to Mono team.
The /pkg option of the mono compiler worked fine for me ...
dmcs test.cs /r:System.Configuration.dll /r:System.dll /pkg:nunit
FWIW, I installed nunit using the apt-get package manager (on Ubuntu) ...
sudo apt-get install nunit

Categories

Resources