I have a dependency folder that I use for dll's in my web application. Some are referenced in the web application, others aren't. However for the application to run I need to have all the dll's in the bin directory of the web application. But I dont want to reference them in the web app. Is there a work around for this? I was considering the post build event to copy in the dll's required from dependencies to bin directory.
If the assemblies are implicitly referenced (required by assemblies you have referenced) they should be automatically copied to the output path. If there are assemblies which you are dynamically loading with reflection like form example some plugins you will need to copy them manually to the bin folder. A post-buid event seems like a good approach.
You can use PostBuild event as you mentioned or edit the project file to include MSBuild Copy Task.
Check: http://msdn.microsoft.com/en-us/library/3e54c37h.aspx
Related
I have used Specflow/MSTest to create a test suite. I need to be able to package this so that a third party can run the tests etc.
I can use vstest.console.exe to execute the features/scenarios using a number of .runsettings I have.
Problem I have is how to copy the files from the Microsoft.TestPlatform nuget package to my project output folder (whether same folder, sibling folder whatever; that is not an issue, I can work that out no worries). I just can seem to work that out.
I have read a number of posts, on SO and elsewhere, with folk asking same/similar questions but I just cant repro how to do it.
Have tried editing the project file to copy PackageReference 'always', using the 'None' element etc but just can't seem to get it. Microsoft.TestPlatform is used extensively so I'm guessing that i'm missing something simple here; I just cant get Google to be my friend in this instance.
So, if my .NET5.0 (framework may be irrelevant) project has a Nuget Package referenced but is not referencing it in code anywhere how do I instruct Visual Studio to copy the files from that package to whatever folder I need them to go when I do a build?
Try to modify the package management to "Packages.config", it will auto copy the dlls to output folder.
If you want to copy dlls to other folder, you can use xcopy command in post-build event.
dotnet publish is the command you're looking for
dotnet publish compiles the application, reads through its dependencies specified in the project file, and publishes the resulting set of files to a directory. The output includes the following assets:
Intermediate Language (IL) code in an assembly with a dll extension.
A .deps.json file that includes all of the dependencies of the project.
A .runtimeconfig.json file that specifies the shared runtime that the application expects, as well as other configuration options for the runtime (for example, garbage collection type).
The application's dependencies, which are copied from the NuGet cache into the output folder.
https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-publish
I have 2 c++ projects in a solution.
ExecB (an executable) depends on ProjA (a dll).
So in ExecB's properties I add ProjA as a reference, and select Copy Local = true.
The problem is, ProjA's dll isn't being copied to ExecB's output folder folder. So the executable obviously doesn't run.
Any suggestions ?
For C++ projects, the Visual Studio template/wizard sets the Output Directory to a subfolder of the solution: $(SolutionDir)$(Configuration)\. This is so the DLL Search Path works well for the developer. It even works if you have added projects to the solution from outside the solution folder hierarchy; The build will put all binaries into the output folder for that solution.
If this isn't working, check the Output Directory property on all platform/configuration combinations of all your projects. Also make sure that the Build Configuration Manager shows that your selected solution build is building all the projects appropriate for the solution platform/configuration.
The Copy Local in Project References that you are trying applies only to referenced .NET assemblies. The docs are ambiguous and too terse on that. (Most often undistinguished use of "assembly" means .NET assembly rather than WinSxS assembly.)
I'm planning to test an upgrade from NHibernate 2 to 3. First port of call seems to be to remove the reference to NHibernate.dll from the website project.
If I simply delete the file from the bin folder, it reappears when I build the website. So the website knows it's supposed to be there. If I open the properties for the website and look at the list of references, NHibernate.dll is not there. In fact, none of my binary references are there, only the project and .NET references.
That's me stuck. Anyone help?
Could it be that you have other libraries referencing NHibernate (e.g. BusinessLogic or DAL)? If so, you need to change the reference there.
If that is not the case, try replacing it in the bin folder directly. Don't forget to replace the other DLLs as well (Iesi.Collections.dll for 3.1 and Iesi.Collections.dll, Remotion.Data.Linq.dll, Antlr3.Runtime.dll for 3.0, and the DLLs for the proxies (lazy loading).
By the way, something that proved to be helpful in such situations is having a designated folder for all external DLLs that do not belong to the .NET Framework and referencing the DLLs from there. In doing so, when updating you only need to replace the DLL in that folder and it will automatically be used.
I'm working through installing the N2 content management framework in an ASP.NET website project.
The instructions at http://n2cms.com/Documentation/Content-enabling%20an%20existing%20site/The%20first%20content%20class.aspx recommend I create a lib folder to hold the required dlls. The very next step asks me to reference those same dlls - which will presumably add them to the bin folder! Thus my project will contain duplication copies of the dlls.
Can anyone suggest why this recommendation has been made?
Thanks
David
The project will not contain duplicates. The bin folder is where the output goes, but it is not considered part of your actual project and is not checked into source control.
By placing the DLLs in a lib folder, it makes it easier to distribute them with the source of your application and ensures that anyone else who gets a copy of your code, whether you send it to them or they grab it from source control, has the necessary DLLs to run the application. It also ensures that they are use the same version of the components that you used to create the software. If the DLLs require licensing, it can be a different story because anyone who wants to compile the project would need the licensing component for the DLLs installed on their workstation.
Basically, the main benefit I see is that it keeps all components used by your code in the same place, making your project one whole unit.
If you add the DLLs to the bin folder, then one day decide to clean your project, they will disappear... So it's good practice to keep your reference DLLs out of the bin folder.
Actually there's quite a few ways the DLLs can be accidentally removed from the bin folder. Just think of the bin folder as a transient location, the contents of which can be refreshed at a moment's notice.
During the build process all relevant files will be copied to the bin folder, including config files, content files marked for copy to the output folder, and of course, any referenced DLLs marked for Copy Local.
If the duplicate locations bother you, you can keep the DLLs in another folder, and just add the containing folder path to the PrivateBinPath of the current AppDomain, which will ensure they get loaded without requiring the Copy Local property.
Let's say you have a class library project that has any number of supplemental files that also need to be included with the compiled assembly (e.g. simple text files or even a legacy unmanaged DLL that's wrapped by the assembly as an interop layer). While embedding the supplemental files into the assembly itself is relatively straightforward, we have situations where this is not possible or just undesirable. We need to have them as "sidecar" files (i.e. files alongside the assembly, potentially in subdirectories relative to the assembly)
Adding those files to the project with an appropriate value for "Copy to Output Directory" specified appears to be sufficient for projects that are completely self-contained within a solution. But if a separate project in another solution adds a reference to the assembly, it does not automatically pickup its sidecar files. Is there a way in the project to somehow mark the resulting assembly such that anything referencing the assembly will also know it needs to include the associated sidecar files? How do you do this?
You can use al.exe, but there also appears to be a C# compiler option. You want to create a multifile assembly using the /linkresource C# compiler option. Instructions are here, but the command is similar to this:
csc /linkresource:N.dll /t:library A.cs
Where N.dll is a native DLL that will go wherever the managed assembly goes (including into the GAC.) There's a very clear description at the link I provided.
Have you tried creating a setup for your solution ? There's an option of including sidecar files targeting to application installation directory.
Another option would be to include the sidecar files in the Assembly resources and un-wrap them to disk when run for the first time.
What if you create a merge module containing the library plus its dependencies? Your installer will then need to reference this module, but you will ensure all of the necessary files will be present.
Unfortunately there doesn't appear to be a lot of built-in support in Visual Studio for this, although I can definitely see the use case.
If you use Subversion for your source control, then you could link in an external reference as an externals definition. This would bring in the source code, and you'd be making a reference to the necessary assembly as a project reference instead of a DLL reference, and then the copy to output directory rules would come into play.
If that's not possible, another solution would be to include commands in the pre/post-build events of your in-solution project to copy the most up-to-date sidecar files from the remote assembly on a build. Of course this comes with the caveat that it doesn't set itself up automatically when you include the DLL in your project; you have to take manual steps to set it up.
I deal with this some time ago. Its a common problem.
You can create some postbuild actions:
http://www.codingday.com/execute-batch-commands-before-or-after-compilation-using-pre-build-or-post-build-events/
Hope this helps... :)
It appears to me that you're using the wrong type of reference. There are two types of references- Reference and ProjectReference. Reference is an explicit reference to a specific assembly. ProjectReference is a reference to another project (say .csproj).
What you're looking for is ProjectReference. VS and the default MSBuild targets are setup to do CopyLocal. If you set CopyToOutputPath true for your "sidecar" files, any ProjectReferences to this project now will also pull in the same files.
I'm not sure if you can to ProjectReferences across solutions in the IDE. I deal a lot with MSBuild where sln files are not relevant and this is how I deal with it.
What we did in our project is that we created as separate build file to do all those stuffs.
In your build file you can have tags to build your main solution, then add tags to copy files you need after build.
NAnt is also your option, but right now I'm happy using Rake as my build/debug automation.
Since this cannot be integrated within Visual Studio, what I'm doing is I create a task (either in MSBuild, NAnt or Rake), that executes vsjitdebugger.exe in the end to attach it to my Visual Studio when debugging.
These are just my styles for now, you can maybe create your own style.