I am trying to create an app.config that allows my WPF application to probe into a local lib folder. However, I am not getting an exe version of my app.config when building my project. Renaming the .dll file does not work either.
Edit: I am using .NET Core
In .NET Core project the generated exe is just a bootstrapper. Your application resides in a DLL file. So it makes sense that the config is also associated with that DLL.
Related
I'm working on a C# application which requires integrating with another company's software. I have isolated all of the code that is tightly coupled to this integration in a single C# project. This way, if the company changes something with their integration, I only have to change code in this one project. The project is a non-executable class library (Project A).
One weird/annoying part of this integration though is that it involves manually copying compiled .dll files from the company's SDK into the bin directory of the project after the project is built. I can't just use a nuget package or something similar. While annoying, I have automated it with a post-build script and it works well enough for that specific project.
I then reference this project/class library from an executable class library, such as a .NET Framework Console project (Project B).
Now I have a problem:
Build Project A
Runs post-build script XCopy C:\CompanyIntegration\Autofac.dll "${TargetDir}".
Compiles without any issues.
Build Project B
Compiles Project A, copies .dlls from Project A bin to Project B bin.
The copied Autofac.dll from Project A overwrites one installed via a nuget package.
The build throws an exception because it expected a different Autofac.dll.
How can I tell the build process to differentiate between these two different Autofac versions/dlls?
Why are the company integration .dll files copied from the bin folder of Project A to the bin folder of Project B in the first place?
I have created a system which loads dynamically a library and executes it's main class.
Everything works perfect, the problem I have is how to publish this DLL with all it's dependencies. As no executable project is referencing it I have to manually retrieve the dependencies: try to load the library, check the needed DLL's, go to the NuGet cache folder, copy the libraries, try again, check if it complains about more dependencies and so on until it has all the required libraries.
This is a true pain and I haven't found any information on how to do this, is it possible or am I stuck with this?
The library is a .net standard 2.0 library, I did this before with .net classic and the output folder always contained all the required libraries even the ones comming from a NuGet package, but with .net standard something has changed and now only libraries from referenced projects are being copied, no referenced NuGet package is being copied to the output folder.
Cheers.
Try:
dotnet publish
All the dependent libraries should be copied to the publish output folder.
At the time of writing, it looks like it's by design and there's quite some fuss and confusion about it, see logged issue on GitHub.
Moreover, when publishing a NuGet package for project A referencing project B,
B becomes a NuGet dependency in A; B's assemby is not included in A's NuGet package.
I deal with it by publishing my own NuGet packages.
I only don't like it to have a NuGet package for project B if that one is only relevant to be used with/by project A, as it will appear seperately in my NuGet feed.
TLDR: Convert your Class Library project into an Application, publish the application, and use application DLL as a library.
The long of it:
I tested this approach by deploying a full build with a plugin with many external dependencies to Ubuntu 18.04 and it ran perfectly.
Create a new project of type Console Application instead of Class Library. Put all your library code files into the Console Application and add the dependencies. Get rid of your original Class Library project (you don't need it anymore). Finally, publish the Console Application. You will get a DLL with all of the dependencies. You can use this DLL like any other DLL.
I suggest naming the console app project with "Library" on the end of it and adding a README just to document its not really an application even though the project is configured to build as one.
Is it possible to make Visual Studio to copy all dependencies of referenced projects into the output path?
Example
In the Solution, Project A (Library, .NET Standard) defines some functions and is dependent on Library L1 (via NuGet) and Library L2 (local .dll, referenced and copied to project)
Project B (Console Application) references Project A.
When building B, The output folder contains all direct dependencies of B and A.dll. L1 and L2 are not available in the output. Therefore, the program does not work correctly.
How can I force VS to copy also L1 and L2 to the output of B?
The only way I found so far is packing A as NuGet, but this seems to be unnecessary overhead and uncomfortable. I think I am just forgetting something everyone else seems to know...
Edit (clearifying Example)
My solutions consists of two projects.
Project MongoWrapper
.NET Standard 2.0 class Library
depends on NuGet MongoDB.Driver package
Actually uses this dependency (no zombie dependency)
Project ConsoleUser
.Net Framework 4.6.1 Console Application
References MongoWrapper project
Actually uses MongoWrapper
Observation
When debugging the ConsoleUser application, it compiles and starts. During runtime, when it calls a method in the MongoWrapper which uses the MongoDB.Driver, the application crashes, as the MongoDB.Driver dependency was not copied into the output folder of the ConsoleUser.
How to fix this?
The problem was introduced by the usage of .Net Standard library and a .Net Framework application.
TLDR
Open the .csproj file of the .Net Framework project with a text editor. Inside the first PropertyGroup add the line
<RestoreProjectStyle>PackageReference</RestoreProjectStyle>
Save the file, reopen Solution in Visual Studio and perform Clean & Build
Dependencies in different project file versions
.Net Framework projects use an old version of the .csproj project files. References/Dependencies are stored in the additional packages.configfile. By default, building a .Net Framework project makes the system to search for a packages.config file in the referenced projects. If no such file is found, the build task treats the referenced project as having no dependencies. Therefore, in the example, the MongoDB.Driver library is not added.
By adding the proposed line in the .csproj project file, the build task searches the project file of the referenced project for dependencies, where they are stored in .Net Standard project files.
.Net Core projects by default search for the newer project file structure.
The default behavior for new projects can be set in the Options -> NuGet -> General -> Package Management
Is it possible to make Visual Studio to copy all dependencies of referenced projects into the output path?
Yes.
This is what publishing the application does - it prepares the application for deployment. When you publish, it will include all of the dependencies that the application requires to run in the output.
Use the Publish tool to deploy to a local folder. The exact options available depend on your app type. In Solution Explorer, right-click your project and choose Publish, and then choose Folder. For more information, see Deploy to a local folder.
Tutorial: Publish your Hello World application with Visual Studio 2017
Also see: .NET Core application deployment.
Sorry if this is an obvious question, but I'm new to C# and am trying to use 2 dll's for a project. Where do I put them?
I tried to add SoundTouch.dll as a reference in an empty C# project, but Visual Studio said to make sure that the file is accessible and that it is a valid assembly or COM component. I was suggested to put the dll's into the \bin\debug path, but where is that? Thanks for your help.
Each project should have it's own \bin\debug (and \bin\release) directory structure under it's project directory, but they will not be created until you Build the project. As for the invalid assembly, it sounds like your dll has either become corrupted or is not a valid .NET assembly.
Edit: Looking at the SoundTouch website, someone has already created a wrapper for this dll suitable for use with C# and it can be found here
If your DLL is a .NET or COM DLL, you can simply add a reference in Visual Studio. For details on that procedure see
http://msdn.microsoft.com/en-us/library/wkze6zky(v=vs.110).aspx
If the DLL is a Win32 DLL (does not expose a COM interface) you can interface with it via the Platform Invoke (P/Invoke) mechanism.
http://msdn.microsoft.com/en-us/library/aa288468(v=vs.71).aspx
When using P/Invoke the DLL must reside in a location that can be resolved by the .NET runtime, and you use the DllImport attribute to "pull" entry points from the DLL into your C# code, e.g.
[DllImport("msvcrt.dll", EntryPoint="puts")]
.NET will search for the Win32 DLL in the same directory where the .exe is located. If you build under Visual Studio, a folder will be created under your project folder
bin\debug
for a debug build, or for a release build
bin\release
A friend and I are working on a ASP.NET website and that friend decided he wants to employ the NHibernate framework for ORM. I have zero experience with using non-standard frameworks, he has more experience though not in .NET but in Java.
The problem is he committed his changes to the project to a subversion repository after he got it all working locally, but when I update, VS gives 7 errors and a warning about not finding the NHibernate assembly references. He just added the references to the project. There is a bin folder in which some dll.refresh resides (this file causes the warning) that points to a full path name on my friends computer (bad thing in other words).
He and I would like to know, what is he doing wrong? How can we embed the DLLs in the project?
He needs to commit the original assemblies to subversion from wherever he referenced them in the project. For example he could create a lib subfolder to the project in which to put all third-party assemblies. Then reference from this lib folder and commit it to subversion. Then when you checkout you will get this lib folder and the application will compile locally because all the necessary dependencies are part of the source control.
You can put the dlls you need in ~\bin and check them in
You can put the dlls on the level above, say in External Assemblies folder, and edit .redresh files to use relative path
But I recommend you, first, convert your project from Web Site Project to Web Application Project, what brings a lot of benefits, including compiling web site in a single assembly, and second, use NuGet (VS package management extension) to reference, control and maintenance any 3rd party libraries and other dependencies via it.