I built an application in dotnet core 3.1
and after build i see in bin folder Lots of dlls and xmls
here screen shot
And I want it to look like this
someone can please help me :-((((
In .net framework you can use AssemblyBinding probing in app.exe.config and use Post Build Events Command Line in Visual Studio to move your dll and xml in the custom folder.
In .net core 3.1 additionalProbingPaths seems doesn't work fine but you can still use Post Build Events Command Line to move your xml in the custom folder.
Note:1. AssemblyBinding probing and additionalProbingPaths will affect your assembly load dll location.2. If you don't know Post Build Events Command Line see the guide line.
See the below issues about probing path.
Additional probing paths for .NET Core 3 migration
donet/sdk issue.
Finally I found nulastudio.NetCoreBeauty library which seems like you want feature.
I am trying to code an application in C#.NET Core that can be extended using MEF. Currently, I am able to do that without any issues with libraries, that have no dependencies or have the same dependencies as the host app (so dependencies are already loaded). But, if I want to use a library with a NuGet reference, that is not used by the main app, the loading of this library fails on that reference.
How can I force the main app to load the missing NuGet dependency, if it tries to load an assembly with such reference? It seems to me as a pretty common use case, but I am lost here and cannot find a way out. Thanks.
For reference, I am posting the portion of the code.
[ImportMany]
private IEnumerable<Lazy<IService, IServiceMetadata>> _asrServices;
...
var catalog = new AggregateCatalog();
catalog.Catalogs.Add(new DirectoryCatalog(Path.Combine(Directory.GetCurrentDirectory(), "Services")));
CompositionContainer _container = new CompositionContainer(catalog);
...
foreach (Lazy<IService, IServiceMetadata> _service in _asrServices)
{
var _serviceInstance = _service.Value // here the loading fails
}
Jiri
.NET currently has two build "systems". One is the original project files, that import Microsoft.Common.props and Microsoft.CSharp.targets (assuming it's a c# project) and lots of XML in between, that has been around ever since .NET was first released, apparently in 2002. Since .NET Core was made generally available in 2016 there has been a new project system generally called SDK projects because the way a *proj file references the build system is though an Sdk element or attribute in the msbuild xml. Although it's off-topic, because there's a common bad assumption, I want to point out that although SDK projects were created for .NET Core, you can target the .NET Framework from SDK projects.
With the original project files, when you build, all the projects references get copied to the output directory. However, with SDK projects, only the project's assembly is copied to output (I'm not sure, but I think even content set to copy to output doesn't actually get copied on build). In order to get everything in a single directory, you should use the dotnet cli's publish command.
So, if you have a build script that builds your project and copies all the plugins somewhere, you should add a dotnet publish step to the script for each plugin using the SDK style project file.
I have issues with ClearScript. When I use them from regular project (class library or wpf), when dependency is added through nuget, also a post build script is added that copies ClearScriptV8-32.dll, ClearScriptV8-64.dll, v8-ia32.dll and v8-x64.dll to bin directory and everything works well. But when I try to use this library with new ASP.NET, things go wrong.
Nuget ClearScript package for dnx is downloaded to
C:\Users\lukasz\.dnx\packages\ClearScript.V8\5.4.3\lib\net40
I mean, ClearScript.dll is there but those 4 other files are not (they are ..\..\tools\native\{x86,amd64}\*, just like in case of desktop app), and when I run app it says
System.IO.FileNotFoundException: Cannot find file 'C:\Users\lukasz\.dnx\packages\ClearScript.V8\5.4.3\lib\net40\ClearScriptV8-32.dll'
So following my experiences from regular projects, I just copied those 4 files from
.dnx\packages\ClearScript.V8\5.4.3\tools\native\{x86,amd64}\*
to
.dnx\packages\ClearScript.V8\5.4.3\lib\net40
And then I get this error
Error: error CS0009: Metadata file 'C:\Users\lukasz\.dnx\packages\ClearScript.V8\5.4.3\lib\net40\v8-x64.dll' could not be opened -- PE image doesn't contain managed metadata.
error CS0009: Metadata file 'C:\Users\lukasz\.dnx\packages\ClearScript.V8\5.4.3\lib\net40\v8-ia32.dll' could not be opened -- PE image doesn't contain managed metadata.
I would asume that those dlls are somehow not valid for web version, maybe I need to get those dlls in some different way?
I could reproduce the issue creating new ASP.NET 5 project from WebApi template. I use single framework dnx46, no core as the projects I use are not compiled against it anyway. I use ClearScript.V8 5.4.3. DNX SDK version is 1.0.0-rc1-update1.
I am simply creating
var engine = new V8ScriptEngine();
in the controller method.
Ok so I am trying to use the Palo DotNet SDK to access the OLAP server.
First I created an empty c# project, added the reference to Jedox.Palo.Dll.
It seems Jedox.Palo.Dll uses two other dll's namely 1. libpalo_en.dll 2. libpalo2.dll
(which are not type libraries themselves so can't be added as a references. See error below for more details on that).
So I read somewhere on SO that I need to add them to the Debug/bin directory of my application, and on doing so still got the error in the title. Then I changed the target framework from 4.0 to 2.0 and viola it worked!
So I then set out to do the same for a ASP.Net Website
I added the reference for the Jedox.Palo.Comm.dll and added the two other files to the bin directory. Image here: http://img200.imageshack.us/img200/6835/paloerror.png
But then I get the error message again. I have done everything I did in the C# application - Add the dll's to the bin dir, change the target framework to 2.0.
Here is the detailed error:
Warning 1 C:\Users\Development\Documents\Visual Studio 2010\WebSites\TestPalo\Default.aspx: ASP.NET runtime error: Could not load file or assembly 'Jedox.Palo.Comm.DLL' or one of its dependencies. The specified module could not be found. C:\Users\Development\Documents\Visual Studio 2010\WebSites\TestPalo\Default.aspx 1 1 C:...\TestPalo\
Here is the error message (pop up) if I try to add libpalo_ng.dll or libpalo2.dll as a reference:
A reference to 'C:\Users\Development\Documents\Visual Studio 2010\WebSites\TestPalo\Bin\libpalo_ng.dll' could not be added. No type libraries were found in the component.
So how can I overcome this. And if you're suggesting Reflector, it doesn't even tell me that Jedox.Palo.Comm.dll uses the other two dll's. So I'm not certain of its efficacy.
And is there like a separate folder where those two dll's need to be put, since this is an asp.net webite, since I feel that if it worked as a C# Application, there is no reason not to work as a web app.
Also should I add any references to those other two dll's int the web.config file?
Thanks in advance!
Solved. Just added the two depended dll to the sysWOW64 folder. Nothing else worked!
When running .net site, enable 32 bit Application in the IIS app pool configuration. Palo requires 32 bit.
I'm getting the following error:
error CS1704: An assembly with the same simple name
'Interop.xxx.dll, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=null has already been imported. Try removing one of the
references or sign them to enable side-by-side.
Everything I've seen says that I am referencing two assemblies with the same name and I need to remove one of them. However, I've checked and I'm only referencing it once.
This also only happens when I'm using msbuild to build from the command line on my dev box. If I build through Visual Studio or do a clean build on our CI server I don't see this error.
I've tried completely removing all of my source and building from scratch to more closely resemble the build machine but no luck.
So it looks like I can't read today!
The project had a reference to the Interop and a COM reference that generated the "same" interop. So there were two and I just didn't search very well. I still don't understand why it worked in other places but this did fix it.
In the Error List window, the project that was triggering this error was listed in the Project column. I got around the error by doing the following:
I unloaded the listed project (right-click => Unload Project)
Opened the XML for edit (right-click the unloaded project => Edit {ProjectName.csproj}).
Searched for the offending .dll, and noticed it was listed multiple times in the XML
Removed the entire Reference tag related to the offending dll, and did so for every copy of the reference except the first one listed
The reason it was listed multiple times was because several referenced libraries used that dll. This shouldn't be a problem, in and of itself, so I'm not sure what caused this error to suddenly pop up for me. I'll update this answer if I figure that out.
In my case the duplicate entry was caused by a NuGet package reference and a direct file reference to the same assembly in the packages folder. I am not sure how the project got into this state, but unloading the project and searching the XML file for the offending assembly name resolved the issue for me.
Note that in my case this started happening after updating a NuGet package to a newer version with no other changes to the project, so this maybe caused by a bug in NuGet.
If this is a web project, are there any strong-named references to the other version there? Those won't show up as a project dependency, but will cause a run-time error like you describe. Hope that helps
I had this problem but in my case, I had an old copy placed in the current folder for the EXE loading my component, that was loaded together with the current one, that was loaded by hand from my projects folder. Deleting that old copy solved my problem.
I used Debug > Windows > Modules window to see which modules were loaded at that time and that solved my problem.
For others facing the same as me: if building via command line using property AssemblyName, it will overwrite all assemblies generated by all solution projects - in other words, you will end up with (N -1) assemblies named the same where N is the no. of projects - the startup one (which generally will generate an exe).
This happens because all build command line properties are global and overwrite any project-specific setting. See this and this.
From the msdn link mentioned above:
Global properties are properties that are set by using the
/property switch on the command line, or properties that are set by
the integrated development environment (IDE) before a project is
built. These global properties are applied to all projects that are
built by using this Engine.
In my specific case, where Jenkins is the CI tool, I ended up adding a windows batch command at the end to rename the .exe only to what I originally intended when passing the AssemblyName parameter.
For those developing UWP projects that have project references that include specifically the Microsoft.Windows.SDK.Contracts nuget package (or other dependencies that reference it), this is a common error when the version of the SDK contracts is targeting a different version of the runtime to how your project is configured.
For instance, when targeting Windows 10, version 1903:
Any dependencies or reference projects should target or at least support the same runtime version.
it is common thought process to update all NuGet packages when a new stable version is available, but this is not always a helpful practise on its own. Just because a new stable version of a package is available does not mean that you should or that you can easily use that version.
Even though this package for SDK contracts has a stable update, it is not compatible with my main project configuration, Nuget does not know this so it allows the update.
This package is specifically designed to provide windows dlls for project types that DO NOT have windows platform targeting support, it copies the same dlls that are included by the UWP targeting config. By installing later versions of the package the references from the satellite project will be included in the output along with those provided due to platform targeting, ultimately causing OPs error.
There are similar SDK and targeting packs for Windows IoT Device Runtimes, this information should help you identify and resolve those issues if you get stuck on this issue as my team often does :)
In my case, the issue was on wrong characters in the ProjectReference section of my csproj file.
Background
I have a project that references another library I maintain, which I publish as a NuGet package.
Whenever I make changes to my library, I usually reference the local dll in my project to test and make sure everything looks good before I publish the library as a NuGet package.
When testing, I just comment out the PackageReference line and uncomment the ProjectReference one so it references my local dll, like so:
<ProjectReference Include="..\..\my-class-library\MyClassLibrary.csproj" />
<!--<PackageReference="MyClassLibrary" Version="2.0.1"/>-->
Root cause
I had the slashes inverted, so I was using / rather than \ in the path, like so:
<ProjectReference Include="../../my-class-library/MyClassLibrary.csproj" />
Once corrected, the issue went away.
Try this instead: remove Interop.xx.dll from the reference section in Solution Explorer and Rebuild the project
In our case this error was shown when we had a duplicate reference inside the .csproj file (although I have no idea how this happened).
The difference to an already posted answer is that, in our case, one was a project reference and another one was direct binary reference to a dll.
Once we removed one of those, project correctly compiled.