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.
Related
I have just learned and created a shared project in visual studio 2017. I have noticed that the shared project did not have the "Reference" to refer to other resources (other projects, class library, …). I even take a look at the .shproj file and saw that it only Import the class I have created inside the shared project.
My problem is that if I want to create an add-in app, I need use the class library to call the necessary API that is exposed by the origin software.
How can I reference/add other project/ class library (or resources in general) to my shared project? Or is that even possible at all?
Part of my problem is also described here reference to a shared project from other shared project
But I need a more general solution. Thank you all for your help.
Long story short: shared projects don't, and realistically can't work that way.
In Visual Studio a shared project is just a container for files - source code, resources, etc - that you can add into other projects. This can be useful in some cases when you want to have the same code (and so on) in multiple projects without putting that code into a library.
Shared projects do not have references, do not have NuGet packages or anything, just the files that they contain. They don't even have the configuration data required to compile any source files they contain, and the compiler won't do much validation of the contents if the shared project isn't included into a full project of some sort.
And since the shared project doesn't have any way of specifying references or packages then you will need to add those references and packages to every project that links to the shared project. The compiler will tell you pretty quick if you miss one.
While it would be nice to have references in shared projects, it turns out to be much less simple than you might think. The same shared project can be included in projects that target different frameworks, platforms and architectures. Let's say you're building some code that will run on iOS, Mono, Windows .NET Framework and .NET Core, with specific code for each target and some shared code. If you try to add a NuGet dependency to the shared project it's going to blow up in your face on at least one of those. Same with most of the references. Add all the references you need for .NET Core and suddenly the other projects don't compile.
You need to add the reference in the project which consumes the shared project.
As an example, let's say you have "Project A" which references "Shared Project B", and you need to use Newtonsoft.Json in "Shared Project B". Since you can't add a reference to the shared project, you install the Newtonsoft Nuget package to Project A and your code in "Shared Project B" will automagically compile.
There are so many questions posted about this issue. I believe i have read them all and still not having much luck. I have a VS2015 project where i can do all that i have described below without issue. Also note that the process i went through to move the applications and class libraries from 2015 to 2017 was to fully rebuild them in 2017. In any case, i created a new solution in 2017 with new application and class library to prove my issue.
I created a new library call ClassLibrary and a new asp.net web app called WebApplication.
In ClassLibrary i then added a nuget for testing (i have also tested this with a file reference to a 3rd party DLL). In this case i added the AjaxControlToolkit 18.1.0 for testing.
Then in WebApplication project i reference ClassLibrary
I would expect this simple solution and project referencing to copy the dependent DLLS of ClassLibrary to WebApplication project bin. It does not. Prior to moving to VS 2017 this would (and still does in VS 2015) copy the dependency DLL of ClassLibrary in WebApplication's BIN. In the VS2017 project i described above the AjaxControlToolkit is not copied to the BIN, i only see a ClassLibrary.dll but none of its dependencies.
I have tried to "use" the AjaxControlToolkit in the WebApplication project code as some of the posts suggest. This does not work as the assembly is not available in the project and i get build errors. I've modified the .csproj files in so many different ways based on suggestions i have found on Stack, nothing works.
Whats even more strange is that i see the DLL in the bin but not listed in the project References. Even though the DLL is in the bin i am unable to work with it.
What is going on? This is such a simple exercise of referencing and after spending two days on Google searching on this it seems crazy that so many have this issue. Why are these DLLs not flowing all the way to the parent application BIN???
Thanks
In my post i mentioned that these projects originally in VS2015 were then recreated in VS2017. This process converted the original Web Site projects to Web Application projects.
As mentioned here, in a Web Site project when a ClassLibrary is referenced as a project reference "Copies of dependent assemblies, XML document files, license files, resource files, and so on." (this includes installed Nugets in the ClassLibrary) are copied to the project BIN. This is not the case with Web Applications. See here for the differences. Installing the NuGet wherever it is needed is required, it will not be inherited from child references as it is with Web Site projects.
I would like to know how I can share c# source codes between two (or more) .NET Core projects (commandline projects!).
As far as I understand, I can not link to source files in different directories in xproj/project.json based projects. I noticed that it now seems to be recommended to create nuget packages for everything. But is it really necessary for me to setup a private repository and create a nuget package only to be able to share some common source units?
VS2015 contains a template for .NET Core library which may be suitable for building a shared lib. Is it possible to link this lib to a project without a nuget package?
.NET Core Library is an excellent solution for you.
Do it the same way as in standard C# solution - just create the project and reference this project or add a reference to DLL file.
You don't need to use a Nuget, for your own purpose. Nuget packages could be useful to distribute your dll outside.
Clarification:
I miss one point - I'm using VS2015, but I have included Class Library project in my solution, and I'm referencing by project, not by DLL file, and this works fine in ASP.Net Core.
I also have a different project, where referencing DLL file directly working fine, but this is the previous version of ASP.NET app (not Core) - seems NET Core doesn't support this way like as the previous version (yet?).
Sorry for confusing you, sometimes it's too many technologies ;)
So could you just include ClassLibrary project into solution with your project and refer it as a project?
I have achieved this by using source control to branch from my commonly used projects in each new solution, and again merging back to the master branch if I make any changes.
Alternatively, baring in mind that NuGet is only an archived collection of files, you could keep this NuGet package locally, or even create a Template for Visual Studio that has the common libraries by default.
There are a wide range of possibilities that are down to your preference, and current environment state (I.E: Able to setup Source Control, or a package repository).
This is much of an architectural level question where I am stuck at. I was planning to implement nuget onto our enterprise project to get rid of multiple levels of deployment/re-building of projects. Here is the Project structure:
Framework (class lib solution): It is referenced in every other solution
ParentClient(WPF App Solution): It is the host client, it can contain many other module inside it which are different solutions as (3). This also uses Framework dlls
MyClient(WPF solution): This client is a module which also uses Framework dlls
Now presently whenever there is a change in Framework's dlls, the corresponding other solutions/projects must be updated, since in the actual deployment environment(a windows machine/ Client Machine) all the dlls resides in the same bin folder. If I do not update the framework dlls, then the present module won't function, and if I do, it might impact the existing application which do not require the latest framework update although due to the latest changes, it somehow breaks the current functioning. (Remember: This issue is due to the fact that in the ParentClient, we have multiple modules say MyClient, YourClient etc)
I would like to know whether or not we can use Nuget or does Nuget will might help me in resolving the issue...???
Yes, NuGet is the way to go. You can set up a very simple NuGet Server by simply creating an empty MVC application and then getting the NuGet Server project template from... nuget :)
An even easier solution, is to simply host your NuGet packages from a network share. You can then keep all versions of your dll's there, and address them from your CI/Build server. Nuget supports adding a network share as a source, and this is common practice
My SAAS company has two C#.NET products, call them Application Alpha and Application Beta. Both of them reference some libraries that we can call Core.
At the moment, the codebase is monolithic, stored in a single SVN repository with a single .NET solution, and we're trying to make it more modular/componentized. We've split off into separate repositories for the two applications and the core library, but we're now running into the following problem:
Alpha and Beta must reference Core, but we're trying to avoid having a direct code reference because then we're practically back to square one: you would need to check out and co-locate all repositories. So how should we go about referencing assemblies between these components?
Each component could have a directory containing DLLs from the other components that need to be referenced, stored in SVN, but this would mean extra effort any time Core is updated to push out the new DLLs to Alpha and Beta.
Or we could store the DLLs in a central SVN'd location (and/or in the GAC), but that would mean extra effort any time Core is updated for everyone else to pull the new DLLs.
Is there a third option that we're overlooking?
I have something similar in which I have 5 applications utilizing a series of web controls I built. The controls are compiled into a series of DLLs for modularization and the applications that utilize them live on separate servers.
What I do is utilize VS2008's build utility to execute a batch file that copys the compiled (updated) DLLs to the production servers when a Release Build executes.
You do this by going to the project that builds into the DLL (or DLLs) and right click on that project and goto Properties. Then you goto the BUILD EVENTS tab. There you see Pre-Compile command line and Post-Compile command line textboxes.
Therefore your release builds can be fully automated and you never have to worry about DLL hell-like differences between versions of your production DLLs.
Hope this helps,
JP
you could have your rebuild script for Alpha and betat create artifacts (namely build core) and place the result of the core build at a specific location referencing that location.
You could use SVN:externals. It was designed for this type of scenario.
If you want to avoid that, these are probably your better options. I'd avoid putting the files in the GAC, though, unless your core project is very stable, and not changing very often. Having the DLLs local provides much more flexibility.
Each component could have a directory containing DLLs from the other components that need to be referenced, stored in SVN, but this would mean extra effort any time Core is updated to push out the new DLLs to Alpha and Beta.
This could be handled fairly easily with a good build system. This approach has some disadvantages (ie: exectuable depdenencies in the build system), but has some advantages, including allowing each dependent project to have different versions as needed, etc.