I have a c# mvc project (mvc) which depends on a self created dll (dll) and this self created dll depends on some 3rd party dlls (3rd). When I build the mvc project, it triggers the build of the dll as expected but when I try to check the page in a browser getting an error message that the 3rd party dlls cannot be found in the mvc/bin directory (and in the other default places). First question if it is normal that the compiler triest to find these dependencies in mvc/bin instead of dll/bin? I mean it's the dll which depends on them.
The other question is that i tried to solve the problem by copy all the dependencies into mvc/packages and set up hintpath in .csproj file but when I execute nuget restore it fetches the 3rd party dlls from nuget repo. How can I tell to nuget that I have these dlls in a directory already? Guess I have to specify in in the .csproj file, but wasn't able to find how.
update:
I'm working with vscode so any right click magic VS does is unrelated here.
Related
I found several problems while using MsBuild from command line and I think they are all related. There are also separated threads for them. The problem occurs for MVC project, created in VS2013.
First - what is the problem.
My bin folder contains several "*.npl" files + some extra dlls
When project A references project B, which references some 3rd party dll, the dll is not present in the package (or at least not on the server after deploy), however log4net is also not referenced in project A, but only in project B, but it IS being copied to bin (and package).
Environment and settings
My run command is like this:
msbuild projectA.csproj /p:Configuration=Release /p:Platform=AnyCpu /p:VisualStudioVersion=12.0 /T:Build
My machine is running Win 8.1 with latest updates, VS2012 MSBuild(4.0.30319.33440) installed. Server runs Windows Server 2008 RC2 with installed VS2013 and slightly updated MSBuild(4.0.30319.34209).
How it behaves
On my local machine, when I run this command, the build runs OK. When I open the bin folder I can see my 3rd party dlls (including log4net) with no extra files. All was built ok.
When I run this command on server, the same bin folder is now missing my 3rd party dlls (but log4net is there!) and there are also some *.nlp files and mscorlib.dll. The build itself returns 9 warning, mostly this one:
There was a mismatch between the processor architecture of the project
being built "MSIL" and the processor architecture of the reference
"{Several_System_Dll_Are_There}", "AMD64".
And one warning complains about missing SDK. Important to note, that I can resolve these warnings and solving the problem number 1 above (npl files..) by appending this line to the command.
/p:FrameworkPathOverride="C:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0"
Probably the wierdest thing is the fact, that log4net works ok, but my 3rd party dlls are not. I checked csproj files. ProjectA has no reference to log4net. Only projectB references it. And they are referenced exactly the same (I checked the csproj in notepad). Only two differences are, that log4net was installed using nuget and also, log4 net is configuret in projectA's web.config.
As I was searching trough internet, I found these issues in separated threads and solutions were usualy by adding some extra settings to projects, editing csproj, sln, registry, etc. I don't like these solutions. Especialy, when the build works perfectly on my local machine.
The question is - why the server need frameworkPath to be specified? And why it is still not copying some 3rd party dlls? Why log4net works? And most important - Why is it working on my local machine, but not on the server?
Update - solution of 2. problem
So, it looks like I have a solution for the number 2 problem. The third party dll was referenced in GAC. And based on this Include GAC Assemblies in Bin, it looks like that msbuild can't handle that. adding True to the reference itself (MSBuild doesn't copy references (DLL files) if using project dependencies in solution) was not helping. I finaly had to add the reference on the third party dll to the projectA as well and add the Private tag. Now it works.
This is more like a hot-fix than solution. I don't have time for this.. if someone find a really solid solution, that would be awesome! :-)
I am using Visual Studio 10 within a C# MVC appliction.
I have a qustion on a .dll reference. I am using a third party reference called
Ionic.Zip.dll. What I am not sure about is that it currently points to a location on my C: drive.
How and what is the best practice for me to put this .dll so that when I check in the project, others can also see this .dll without it blowing up.
Thanks
I would typically put a Library folder in my application structure, place the 3rd party dll in that folder, and then reference that dll. Then ensure that the library folder is checked into your source control.
Now, anyone that pulls your source will have the required dll.
Even easier...simply add a reference to DotNetZip via NuGet, the Visual Studio Package Manager:
http://nuget.org/packages/DotNetZip
And you shouldn't have to worry about it.
The best way is to use Nuget.
But in some cases Nuget is not available or not getting compative, so as our friend says, its better put a Library folder in application structure, place the 3rd party dll in that folder, and then reference that dll. Then ensure that the library folder is checked into source control. Now, anyone that pulls source will have the required dll.
Our project has a lot of external DLLs, most but not all of which are 3rd party DLLs.
Currently we do not have these DLLs included in our project. They are included in SVN and given a path to our build output directory. So, after building our project the neccessary files are there, because of SVN, but the project itself has no knowledge of them.
My feeling is that we should have a folder under the root of our project named something like Dependancies or ThirdParty with all of the DLLs included there and set their build event to copy to the output directory. They would exist in SVN as well, but in the same structure as the project, not in the build output directory.
The project itself only references one of these DLLs called CommunicationProc.DLL. The CommunicationProc.DLL then references all of the other DLLs. We have numerous DLLs to support different types of radio. So not all DLLs will be used, but any one of them may be used depending on the radio type.
As to whether or not the DLLs should be included in the project we have differing opinions internally, some of the team beleives they should only be in SVN and not part of the project itself.
Of note is that this are not .NET DLLs, most are old C DLLs.
What is the accepted practice? Can someone please provide me with a compelling arguement one way or the other as to whether to include them in the project or just SVN?
Its better to have them in a folder on source control and then copy them over to the debug folder on build event. This way you can manage their versions. If a newer version of some dll comes then you can replace the old one and put some comments with check in. Also if you are working in a team, then instead of copying files from debug folder to each team member, you can let each team member to use the same set of dlls from source control. If you are developing some control and want your customers to use that control then its easier for you to have a set of dependent dlls some where so that you can give those to your customer along with your .Net dlls.
I had the same issue with some un-managed dlls and ended up putting them in a folder so that all the team members have the same version of the dlls. Hope this helps.
I include a project that has no code but contains a folder where all the external assemblies and their dependencies are kepts. For each file set the Build Action to None and Copy to Output as Do Not Copyp. The project then references the binaries from this location. In your other projects, reference this special project. When you build, because the special project is referenced and it references all the needed dependencies, the binaries are copied as needed.
If you do not want a special project, still create the folder in your main project, added the assemblies, set their properties, then reference the assemblies as needed.
This gives you complete control over the versions and output, and more importantly, it is simple.
I'm using a mysql .NET Connector library (Mysql.Data) in my project. As far as I understand it, I only need to use the mysqldata.dll which is in the assemblies folder after the connector is installed. I'm going to be using the program on a computer that has .NET 2.0 but doesn't have the connector.
How do I add the .dll file to a project such that the dll is used internally - I hope that makes sense. If the program calls out to .NET to find it, (as it does) - the whole thing fails and errors out.
In Solution Explorer, under your project, expand References, select the MySql.Data assembly, view the Properties for the assembly, and change Copy Local to True. Now when you compile the project, MySql.Data.dll will be output to the bin directory.
(You will not embed one assembly into another. Instead, you deploy the MySql.Data.dll along with everything else in your build output which is required. This is simply known as adding a reference ... I don't think you really wanted to embed it.)
This has to be a pretty common issue, and while we have answers, I'm trying to determine if there is any better way. We are using IoC / DI with structuremap. This means that our final application (an Asp.Net MVC 2 app) requires the presence of some assemblies which aren't being referenced anywhere else (our implemention of IRepository, etc).
In VS, I've added a Post Build event that simply goes to our lib folder (containing the already build assemblies which are not part of our solution) and copies everything with *Repository*.dll to the $(TargetDir).
On the build server, were we are also building packages for deployment (and hoping to automate deployment to some environments), I've done something similar to get those assemblies.
Is there any better way though? Or do you just accept that this is one of the issues with IoC and have to remember to add a bit of script to include the service assemblies as part of the process?
Thanks
Andy
You should be able to create a project of any type, and then reference everything you need. Then just copy everything, except the dll from that project. At least you don't have to edit a lot of scripts just to add a new project..?
I suppose you could add the assemblies you want into your project just as linked files, not as assembly references, and then mark them as 'Content' as the build type and 'Copy if newer' so they will get copied to your bin folder.
Never tried this, but it ought to work.