Small question : If a dll is being referenced from C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.6.1, how does an application link/finds that during runtime? (or when launched without VS)?
Is it from GAC or the dll is copied into executable location at runtime?
The Framework you build with (4.6.1) has to be installed on the client (GAC) to run. Standard with normal Windows client/server.
If you want to embed the DLL in your EXE, have a look at Embedding DLLs in a compiled executable.
I highly recommend to use Costura.Fody - by far the best and easiest
way to embed resources in your assembly. It's available as NuGet
package.
Install-Package Costura.Fody
After adding it to the project, it will automatically embed all
references that are copied to the output directory into your main
assembly. You might want to clean the embedded files by adding a
target to your project:
Install-CleanReferencesTarget
Related
I have a DLL with tools i use in several projects. The DLL is frequently updated with new functions. How can i automate the replacement of the DLL in a way so that i dont have to manually copy and paste?
The way i do it now is that i build my project with visual studio, manually copy the DLL file from bin/debug folder and paste them into the root folder of the different projects that use it.
I know gacutil is used to register DLLs to the GAC and that i can make a batch file that does this.
If i install it to the GAC and the projects reference them there, will they be updated? What typicall options are there?
You should look into packaging the library as a NuGet package.
If that doesn't work for you, there's post-build events in Visual Studio that you can use so that the copy & paste is done automatically for you.
My application references the Sage50 SDK and I need to support multiple versions of the SDK.
In Visual Studio each version of the SDK has its own project and has the SDK DLL's referenced.
But when I build the solution the DLL's overwrite eachother and only 1 version remains.
I can't rename the DLL's because the SDK loads other DLL's by name and will error out when they are renamed. And they are signed.
How would I go about a situation like this?
Make each project uses a 'strong' reference to those different sage SDK assemblies. That is, make sure it specifies a version, culture, and token etc... Nothing worse than a versionless, sloppy reference.
You will have to output your project DLL's to separate locations. Because the build will copy all dependencies to the output folder.
Because of #2, you will have to dynamically load your assemblies in your application. (i.e. Assembly.load(...))
I have created a new web site using Visual Studio 2017. The target framework for this site is NetCoreApp 1.1. As this is an MVC project, it references a number of Microsoft and third-party dlls from Nuget. I also have a data project that I created as a library. It is Netstandard1.6. When I build the solution, none of the dlls from the Nuget packages are copied to the bin folder. This causes the app to crash with a FileNotFound exception when attempting to debug it. The project references are being copied correctly, so it appears to only be a problem with Nuget packages. As a workaround, I can publish the project and copy that output to the bin folder, but I shouldn't have to do that, should I?
.NET Core uses the generated .deps.json file in the output to resolve assemblies, so it avoids copying the files unnecessarily during the build.
However if some assemblies try to look for other assemblies in the output directory or the files referenced in the deps.json file cannot be accessed (e.g. testing build output in IIS), you can add this to a <PropertyGroup> element in your csproj file to cause the NuGet assemblies to be copied to the output directory:
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
This 'CopyLocalLockFileAssemblies' doesn't do anything on my end. The only way I found to get the content of the 'runtime' folder in my output is to use 'Publish'. This is not a solution to locally debug an application.
Edit :
Adding the Runtime IDentifiers to the project file seems to do it for me.
Also, .NET Core 3.0 fixes the issue but it is only in Preview.
At trying to run a test application i obtain the following error twice:
There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "C:\Windows\Microsoft.NET\Framework\v4.0.30319\mscorlib.dll", "x86".
This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project. TestMobile.Core
mismatch MSIL x86
I have .NET Framework installed, as well as windows 8 SDK tools and using MultilingualAppToolKit.
I already have verified the configuration manager and everything seems to be fine. Platform target, targeting "Any CPU"
Copying over my existing version of .NET Portable Library Reference Assemblies fixed the issue for me.
I encountered this problem after installing a patch to Visual Studio 2015 Update 3, read vvolkgang's response and initially discounted it because I already had folders within C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETPortable, and the dates of those folders were later than those contained within the reference assemblies archive I had downloaded. What I should have done was to check the right part of the folder hierarchy. Take a look at your project file; in my case I had these settings:
<TargetFrameworkProfile>Profile49</TargetFrameworkProfile>
<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
If those are your settings, you need to check the contents of C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETPortable\v4.5\Profile\Profile49. If you're using a different profile or targeting a different version of the framework, adjust the path accordingly. When I checked that folder, I discovered that I had lots of XML files but no DLLs; copying the files from Microsoft .NET Portable Library Reference Assemblies 4.6 and choosing not to replace any files that already existed fixed my build issues.
Had this problem after installing Visual Studio 2015 Update 2. Try this, the first one solved my problem:
Install Portable Class Libraries v4.6
Download Install the Portable Class Libraries v4.6. If you install this it puts a .zip file into the directory:
"C:\Program Files (x86)\Microsoft .NET Portable Library Reference Assemblies 4.6"
Unpack and copy the contents into "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETPortable\"
Install the PCL Tools
Download Portable Class Library Tools
Install by running PortableLibraryTools.exe /buildmachine
Source: Matt Ward # https://forums.xamarin.com/discussion/comment/80535/#Comment_80535
I finnally was able to build my project without this filthy error. It seems that i needed to install PortableLibraryTools from VS2010. It worked after that.
Reference: http://forums.xamarin.com/discussion/25538/xamarin-xaml-example-problem-using-pcl
If you are on a build Server and getting this Error/Warning , just install MSBuild 17 with its optional installations which contains all the SDKs and Portable libraries.
I converted my .net application to .net 4.0 and because im using async/await I installed NuGet packages Async for .Net 4 and dependencies Microsoft BCL...
When I build my application, everything goes well but when I move my app .exe to correct environment I get the error:
System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Threading.Tasks, Version=1.0.12.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a or one of its dependencies.
If I include Microsoft.Threading.Tasks.dll to my applicatin directory everything works well (this .dll is copied to my app build directory).
So the question is do I need to include this Microsoft.Threading.Tasks.dll to my app installer or Is there way to bundle this to my app .exe?
When you build your app there will be a few DLL's in the output folder. Your exe potentially needs all of the DLL's in that folder in able to run.
You should include all of the dll's with the installer that the compiler puts in to the output directory.