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.
Related
The way I am going to do is create a SolutionItems directory inside my solution and physically copy all referenced third-party dll files into that folder, then I change reference to that local copy inside the SolutionItems directory. But the question is: does it worth the trouble of manage it manually?
I would think it is a good idea as it is dependency for my application. Without including the dll file, the whole solution wouldn't be able to run inside Visual Studio if the machine don't have the required DevExpress version installed. My Deployment Project will handle dependency correctly regardless, as far as the reference been setup properly.
On the other hand, because DevExpress will normally automatically add references, and I can using Project converter to update version of DevExpress. So without reference to the Local Copy inside solution, it is pretty much working out of the box whenever I am changing reference, or change between DevExpress versions. If instead, I am managing my local copy, I am create more work for myself to maintain the reference and physical copy of dll files. Should I keep it simple as it is now, base on the assumptions that whoever working with this application will need have a copy of DevExpress installed?
We had a similar problem where I work. 5 devs, 1 svn and mulitple copies of DevExpress dlls floating around. We tried at first maintaining a local copy (updated manually) as you describe, this did not work well for us. So yes, the easiest thing to do (in my experience) is require everyone who works on the project have a copy of DevExpress installed.
For a long time looking for a way to manage references, I haven't found any ideal way.
The main problems are:
1-) Should I include all projects that I use in same Solution and reference the Project? Or reference just the dll file?
2-) If I should reference dll file, the best way is to create a ReferencedAssemblies inside each project or a main folder at svn root?
3-) Its ok paste and reference dll´s inside bin folder of my project?
4-) Its ok add and commit dll´s inside bin folder of my project? This way when a new devoloper checkout the project, it will compile perfect, but isn´t default behavior of visual studio, all source controls ignore bin and obj by default, just adding .refresh files(for web-site project)
Someone can help me?
1) If you include projects in your solution that are already checked in somewhere else, you can change the SVN binding for that project at the solution level in Visual Studio. (File > Source Control > Change Source Control). You would change it to point to wherever it's located in your SVN repo.
2) If you have a lot of developers on different machines all wanting to use the same libraries, it's probably easier to have a common place for all your third-party libraries/assemblies. There's no point in having them copied all over the place in your SVN repository.
3) No, it's not usually ok to do this. I would avoid it (unless somebody has a valid reason for it).
4) Never commit your bin folders. The default behavior is such for a reason. The .refresh files are byproducts of the old Web Site projects and they are fine.
1) In the typical scenario yes, you should reference all projects that you own. But you should make a decision according to frequency of changes made to referenced projects. For example if you have an open source library it is better to include it as an assembly, cos you probably will not change this code frequently.
2) Typical approach is to create separate single directory at SVN root and place assemblies there in different sub-folders according to assemblies type. Here is how my current folder looks like:
3) No, it is better to reference assemblies from some other from bin folder. All referenced assemblies will be copied to the bin while building process. Also note that the purpose of *.refresh files in the bin folder is to prevent you from having to copy new versions yourself.
4) No, you should never commit your bin folder cos you can rely on *.refresh files for WebSites and just forget about this problem for other project types.
1) I'd argue it depends upon your particular situation, especially since Visual Studio is pretty flexible on what projects are included in solutions. (It's not tied to a directory structure.)
We have a couple applications that have one solution with a number of projects contained within (for each 'piece').
2, 3, 4) For referencing and including files within a project, why not just use the functionality built into Visual Studio? Adding references in this way adds the items to your csproj (vbproj) files.
(Based on my research, if you're not referencing a project that's part of the solution, put the DLLs in a directory everyone on the team can access and use that when adding the reference. In the project file it ends up looking like this:
<Reference Include="Elmah">
<HintPath>\\pathInformation\shared assemblies\ELMAH 1.1 32-bit\Elmah.dll</HintPath>
</Reference>
)
This also means that you don't have to commit DLLs; if anything changes the project file will be updated accordingly.
(I'll admit, I'm unsure about that last point. I've seen a lot of people check in external libraries, like ELMAH. I generally follow those who tell you to ignore the bin directory entirely.)
We have developed a library in C#, and now I wish to create a project template to aid in using the library correctly.
I want new projects to include a reference to the library assembly, but would prefer not to have to deploy the assembly to the GAC, or to depend on the assembly residing in some specific location.
What I am thinking is to include the .dll in the project template .zip file. That means it will end up somewhere inside the project folder of new projects. Perhaps in a folder named Lib. Then the reference hint in the project file can point to that folder. Is that a good idea? What problems might I face down the road?
Is there perhaps some mechanism for including such 3rd party libraries in project templates that I'm not aware of? How have you tackled this? Surely I'm not the first.
I have had to address this issue in the past. In one case, it was a logging library that was installed to the GAC, which meant the Reference element simply needed the assembly name. In another case, we installed the library to the file system, created a registry key that contained the location (in case the user got cute and changed the install location on us) and used a project template wizard to look up the registry key and populate a replacement item to have the correct location in the Reference's HintPath. (Note: the template wizard approach requires you to install your wizard's assembly to the GAC, which it sounds like you're trying to avoid...)
If you don't want your library to be installed in either the GAC or a specific location, the approach of including the assembly in the project is pretty much your only remaining option. On the positive side, deployment of your project template is fairly straightforward and you don't have to muck with the GAC, custom wizards, etc. On the negative side, if you ever create a new revision of your library, your users will need to update every project's copy of the library.
I have the following project structure using a Domain Model, StructureMap and Fluent NHibernate:
The problem I'm having is that Fluent NHibernate requires all of the following to be the bin directory of the website for it to work at runtime:
Antlr3.Runtime.dll *
Castle.Core.dll
Castle.DynamicProxy2.dll
FluentNHibernate.dll *
Iesi.Collections.dll *
log4net.dll *
NHibernate.ByteCode.Castle.dll
NHibernate.dll *
The problem I'm having is that not all of these assemblies are output to my website's bin directory. Currently only the items with a * are output correctly. The items in bold are missing from the bin directory.
Now, I would of assumed that the reason for this is because I have not added them as references to my Fluent NHibernate project. The only references I currently have are to NHibernate.dll and FluentNHibernate.dll. These two references alone are enough to bring through the items marked with a *, but they do not bring through the missing items.
So, I then thought that to get them to all come through I'd just add them as references to the Fluent NHibernate project. Unfortunately, this made no difference; the same items were still missing from the bin directory.
I've never really understood how visual studios decides which assemblies to copy over. I always assumed it was any assembly marked as Copy Local=true, but this doesn't seem to be the case in this scenario.
Of course I could just add all the assembly references into Website, but then that'd completed defeat the point of loosely coupling the projects through StructureMap.
Does anyone have any idea why the assemblies are missing and how I can get them to copy over correctly?
You can either add references to the project that requires those files be present in the output directory (Website in your case) or you can add a post-build step in your build script to copy them across.
This is a case of VS and the compiler being "smart" about whether references are actually required or not. The C# compiler optimizes out those references that aren't actually required. Adding a reference to non-required assembly in VS will ensure it appears in the output directory of that project. However, dependent projects will only get that same assembly if it's actually used by the project referencing it. That is, if the C# compiler hasn't optimized its reference out. That's why you would need to add the reference to the Website project, if you go that route.
Personally, I did exactly that. I don't really think this is tight coupling since NH still resolves the assemblies dynamically at runtime. And it's not like I can't just substitute in other byte code assemblies manually and restart my app. But it's also not like I would do that without adequate testing, so in a way I consider myself to be coupled to Castle on the basis of that. And, therefore, I'm not irked by the references.
I have been using the Codesmith framework NetTiers to generate a DAL etc., into a folder called, say, 'NetTiers', outside my main project's folder, and referencing the DLLs within that folder from my main project.
I've started using the Plinqo framework, and want to use the generated files from that framework within the same project as the one I'm using with NetTiers. (The reason I'm using both frameworks is that I want to get/learn the newer LINQ goodness from Plinqo, yet also have the familiar NetTiers code DAL, BLL syntax available, for compatibility.)
My question is: what's the best Visual Studio solution and file structure to use when using Codesmith templates like these? Should the frameworks' generated code be contained outside the main project and added as projects to the overall solution? Or should each template's generated code have its own solution? Should the generated files be within the main project's file structure?
I've tried combinations of each of these, and they each have their pros and cons. I'd like to know if there's a tried and tested pattern.
When it comes to .netTiers, I always compile the generated solution and add the assemblies as references to my project. This makes it much easier to upgrade/diff and regen.
However, there are going to be some cases where you would want to add your custom logic so keep this in mind.
Thanks
-Blake Niemyjski
I tend to just keep the .csp and the generated folder outside of my main app's folder. When adding a reference Visual Studio copies in the .DLLs from the built generated code. All of the generated projects sit under a main folder such as D:\CodeSmith Projects\
If you want to version control the .csp file it might be beneficial to move it in with the rest of your version controlled app files to tie it all together.
We put the generated projects inside our solution. In fact on my current project I generated the nettiers files to the location that I wanted the files to be, and Started adding my own project files to that...But we have always kept the files in the solution, that way if i need to add something to the code in the concrete classes I can do it without having to open a whole new project.
We have tried both scenarios. We settled for including the assemblies in a dependencies folder, which was shared by multiple projects.
We had problems with TFS when the projects were included in the solution. the downside, is that you can't so easily step into the .NetTiers generated code when debugging, though after a while you get used to this, and accept that whatever is in .NetTiers stays within .NetTiers!