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
Related
Running in VS2019 Admin Cmd window -- gacutil.exe error: "Failure adding assembly to the cache. The system cannot find the file specified."
GAC util path: C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7.2 Tools\gacutil.exe
Command line: gacutil.exe -i "DuraSysOrdFuncs.dll" -r FILEPATH "C:\Windows\DuraSysOrdFuncs.dll" ""
I picked this version of GACUtil just because the C# library was built with a target framework of .Net 4.7. It isn't clear to me that it much matters.
Doesn't matter what I put in the 3rd parameter of -r. Doesn't matter where I put my assembly on my local disk. Same error message.
I'm trying to put this in GAC because I need to call it from an SSIS package running on SQL Server 2016. I have opened Sysinternals ProcMon per a suggestion of #HansPassant in a different post. Not familiar with tool so haven't found the file location error. . . if that is the actual issue.
Any input much appreciated
The answer, as the commenters noted, and as ProcMon indicates, is to just include the path for the .net assembly you're registering: gacutil.exe -i "C:\YourAssemblyFileLocation\YourDLL.Dll" That's all it takes. . .you don't normally need -r parameters, etc. Thanks!
You can use powershell to register assemblies into GAC. It doesn't need any specific installation.
Set-location "C:\Temp"
[System.Reflection.Assembly]::Load("System.EnterpriseServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")
$publish = New-Object System.EnterpriseServices.Internal.Publish
$publish.GacInstall("C:\Temp\myGacLibrary.dll")
If you need to get the name and PublicKeyToken, refer How do I find the PublicKeyToken for a particular dll?
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)
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!
There are some c++ projects(vcxproj) in my solution those really interop projects.
All was fine until I tried to re-build them for .net v3.5 (they initially target .net v4.5)
I changed the version string to "v3.5" in the project files, changed the path for ilasm to
‘C:\Windows\Microsoft.NET\Framework\v2.0.50727\ilasm.exe’
and all looks fine.
I built these projects, made a msi package and tried to install it, but got this error:
Assembly Install: Failing with hr=8013141a
Assembly Error:Strong name signature verification failed for assembly '%1'. The assembly may have been tampered with, or it was delay signed but not fully signed with the correct private key.
Product: MY_PROJECT -- Error 1937. An error occurred during the installation of assembly 'MY_PROJECT.Interop,Version="5.3.0.0",Culture="neutral", PublicKeyToken="0DC6B9046BBF1D8A",ProcessorArchitecture="MSIL"'. The signature or catalog could not be verified or is not valid. HRESULT: 0x80131045. assembly interface: IAssemblyCacheItem, function: Commit, component: {84C66D06-D31F-536F-B79F-71F7E5F4BFE3}
I checked my configuration.
I use Visual Studio 2013 and VS 2010 is installed too, and some SDKs.
VS 2013 uses OLD version of SN for signing my projects and this old version is located in the
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\sn.exe"
Just for case I changed the path to sn tool 4.5:
"C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\sn.exe"
and my interop files were installed without any issue!
this is a sequence I use for creating key files:
sn.exe -m
sn.exe -k CONTAINER-Authenticode.snk
sn.exe -i CONTAINER-Authenticode.snk CONTAINER
sn.exe -pc CONTAINER CONTAINER-Authenticode.pbk
Added system variables SN_ContainerName=CONTAINER; SN_Option=-Rc
The my question is, why is that, what version of SN should I use, where can I read something about that, and where can I made any error.
In trying to build NuGet3, I'm getting the following error:
~/Projects/NuGet3-dev/src/NuGet.CommandLine/project.json(22,46): error: The dependency fx/Microsoft.Build.Framework >= 14.0.0 could not be resolved.
I have no idea why it wouldn't be resolved, since according to
gacutil -l
I have it:
Microsoft.Build.Framework, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
I looked at everything I could find about this issue, but it's almost entirely Visual Studio and Windows based resolutions, and nothing seems to apply to my situation...
How to make this resolve?
(Assuming you are working on https://github.com/NuGet/NuGet.CommandLine ...)
How to resolve?
Use Windows. This project is not designed to be built on Mono. It is integrated with Windows tooling.
Under POSIX systems (thought, some true operating system):
In short, the dependency is resolved using DNX or dotnet (said M$ .Net Core), and its restore command.
The fx/ stands for framework, just drop the prefix, it should be the same. I sow these kind of notations disappear, when passing to DNX. Just try and install it using the DNX process.
since MSBuild targets and props for DNX are not available, the xbuild script from Mono won't work.
You'll have to use one of
the "deprecated" dnvm.sh script and dnx/dnu commands to restore and then build each sub project.
Note: that yet isn't anymore available at download, and the call to dnvm update-self relaces the script by a "404" ...
The "Microsoft .NET Core Shared Framework Host", "dotnet" (that I don't use)
It should mostly work, if you've got Dnx, try this command line, from the src sub-dir of the NuGet3 source code:
(for d in *; do (cd $d && dnu restore && dnu build); done)2>&1|tee build-all.log
For me, using Debian-8, there are build failures:
NuGet.CommandLine.XPlat
NuGet.Configuration, but it succeeds for the "net451" framework
NuGet.Packaging.Core
NuGet.Packaging
NuGet.Protocol.Core.v3, but it's OK #dnxcore50 (don't ask me why) ...
YANote: If code cannot be transformed anywhere but by M$, this is cannot be source code for me : I cannot not use it as a source. This is a secret code, a private code ... something to throw away, and that probably no one cares.