I have a big project with many subprojects.
(as mentioned in the drawing)
Both WebSiteA and WebSiteB has referenced to both DLL projects.
however when I change the dll's - I need to update each bin in each webSite.
I Don't want that.
I know I can put them in GAC but I was told not to (don't ask me why please.)
Is there any solution like :
so when I update any dll - I put it only at one place ? (and so the dll's won't be at each site's bin)
You can make a trick with the .refresh file reference, but not tested on the live server.
First place your common dll, on a common directory.
Second on each bin, place the *.refresh file together with the dll, that says inside from where to update the dll if a new version is found.
and so you have inside the Bins something like:
mySuperModule.dll
mySuperModule.dll.refresh
and inside the mySuperModule.dll.refresh the location of the module that need to check for update ->
d:\Dlls\mySuperModule.dll
where d:\dlls are the common place for the dlls that search for new updates.
At the end you only update the common directory dlls, and you left the projects make the rest automatic.
The whole point of the GAC is to provide that functionality, if you don't use that then you can't share the DLLs in the way you want. This is due to how sites are secured and separated from each other.
Related
I have my main solution wish is comprised of 4 projects. There is a precedence chain between my 4 projects, that is 1 needs 2, 2 needs 3 etc. Also, some of these projects use Nuget packages.
Like this:
Project Layout
Now I can get my MainPointOfEntry.dll, and include it my a external solution and it works fine, but I don't see how it knows where to find the dependent .dlls (maybe it is somehow looking in the same solution folder)
External Solution with referenced dll
So my single entry point works fine, but how does it know where to find the dlls of which MainPointOfEntry depends?
I feel if I was to make a copy of MainPointOfEntry.dll and create a solution on a different computer it would not work?
Sorry about this badly phrased question
how does it know where to find the dlls of which MainPointOfEntry depends?
It doesn't. MainPointOfEntry does.
I feel if I was to make a copy of MainPointOfEntry.dll and create a solution on a different computer it would not work?
Depends on if you have embedded the library in output or not. If you have added your dependency and configured to be an embedded resource It will work. If not, you need to copy these too.
I have a project "ProjA" which wraps up references to several other projects and some 'plugin' assemblies. All of those references have Copy Local set to 'True'. Note that the code in the plugin assemblies (which are project references) is not referred to in "ProjA" directly, but is loaded and located through DI/Ninject. (So I'm using these project references as a way of getting the plugin assemblies into the output folder, see below for why)
I also have project "ProjB", which references ProjA. It invokes ProjA code which should do it's thing, using the referenced plugin assemblies.
The problem is, it doesn't work. The plugin assemblies are not copied down from the ProjA output folder (which they are 'copied local'-into) into the ProjB output folder. So Ninject doesn't load them, and the thing fails.
So my two questions:
If I have dictated to VS/msbuild that ProjA refers to projects P1, P2, P3, P4, and set copy local to true - why then would it assume only the main output assembly is required to make ProjA work? Can I make it think any differently?
I'm guessing that adding a Copy Local reference to the plugin assemblies as a way of having VS recognise a build dependency between the plugins and the project using them (currently a fixed set of plugins, hence this route) - is not ideal. I then think that adding the plugin assemblies as 'Content' to the project would work, but then I have two issues: 1) TFS source control; the plugin projects need a writable target to build to, presumably - content files would be 'checked in' and 2) some of the plugins have Content of their own: with references I don't need to worry about missing something. Going the Content route I need to refer to another project's build output folder, include all of it's content, but not the PDBs.. seems even more hacky!
I have also considered and played with post-build steps for either the plugin projects (not ideal: I am pulling them into this new solution from another, if I add post-build steps it will likely screw up the other solution) or the project which depends on them (which is OK, but an XCopy with relative paths, and having to manually set up Project Dependencies.. seems more hacky again).
Is there something I'm missing, any ideas at all? If Copy Local chained across project references it would fit perfectly..
Not possible with Visual Studio or msbuild it seems.
Copy local = true is the source of all VS evils.
Well, most at least.
I'd go with just saying - don't use it. Have one nice outputdir, like T:\Bin, and copy everything you need using post build scripts to that dir. And run from there.
Don't just put your trust in VS and walk around like a blind mice.
You may also consider using the GAC.
I just opened a solution from TFS using Visual Studio 2010. The solution contains more than 100 projects (if up to me, it would probably be less than 5) and many of them happen to miss a reference (to Unity dll's).
Is there any way to simplify the fixing of these references? Now I have to delete and re-add all of them manually. Hassle.
Any suggestions would be appreciated.
To fix the problem you need to find out from where it tries to load the files. You can do so looking in the project csproj file. You either have newer (or different) versions of the assemblys installed or you have a different file and folder structure. You need to recreate the file and folder structure that has been used in that project or rewrite the csproj file to the new location.
For the future you might want to change how 3rd party references are handled. I have good experiences using this approach: Define a ThirdPartyLibraries Folder where all those libraries go and check it in. It should be in the solution folder. Everybody has to put 3rd party libs in there from now on and use them instead.
Might want to check out resharper, it might do what you need for references. I know it helps optimize and identify references in classes, not sure at the project level. Resharper has a 30 day trial
You can add all those binaries in to Binaries folder and add in to your TFS.
Now add the binaries as existing item in your solution items, so that when you open the solution it fetches all the solution items as well.
Make sure the references are added from the binaries folder.
If the location of the referenced assembly has changed, then it is relative simple to do a Find and Replace in files on the .csproj files to replace the broken reference with the correct one.
I currently have a program that i wrote that is divided up into 3 separate solutions.
Front end (all display related stuff)
Parsers (multiple (39) projects that each create a dll to parse specific data)
Globals (multiple (5) projects that each create a dll that is used by projects in the parsers solution, and by the front end).
Requirements -
Both the Front end and Parsers require the globals dlls to exist at compile time, and used at run time.
The Parsers dlls are loaded at run time using assembly.LoadReference.
Development is: C:\projects\myProg
deployed location is: C:\myProg
My problem is that I have been going back and forth with issues dealing with project dependencies, where to point to for my globals dlls. Do I point to the deployed location or the developement location, and if so, release or debug?
So I started looking up the different solution types, and I'm wondering if I should set up a partitioned solution, or a multi-solution for my particular situation.
Add all the projects to a single solution.
Change any references between projects into "project references" rather than direct references to dll files. This will fix a lot of dependency issues.
If you have any "library" files that are not changed often, then you can optionally move them into a separate solution. The output of this should be "prebuilt" release dlls that you can then reference from a standard location in your main solution (the best way to do this is to add a post build step that copies the output to your development "library binaries" folder. That way, the build process is not changed, you simply add an extra step to get the files where you need them, and you remain in full control of the build process). This works well, but is a pain if you need to change these prebuilt dlls often, so it's best only used for fairly static parts of your codebase.
Finally, consider merging many of your projects into a single project/assembly. The killer on build times is not the amount of code, it's the number of assemblies - on my PC every project adds a pretty constant 3 seconds to the build time, so by merging small projects I've saved quite a bit of build time.
Since those 3 are all part of the same system, it will probably be easier to have a single Solution with each Project added to it.
NOTE: You do not need to move anything from their current locations.
Just create a new empty solution and do a right-click Add > Existing Project... for each project you want to be a included, they will remain where they are on disk, but will be opened together.
The current ("old") solutions will be available as well, just as they are.
Also keep in mind that if you are editing the same project in two instances of VS at the same time, it will bug you about reloading the source code when a change is made and saved.
Most importantly, having the projects in the same solution will allow you to add references between them, rather than the DLL files.
why are they scattered into separate projects, Combine the Parses and globals into a single assembly. keep the UI assembly separate and as simple/small as possible.
Let's say you have a good reason for having so many projects (example: different amount of parsers available for different licenses of a product).
Managing dependencies in visual studio is made easy:
Right click your solution node
Select "Project Build Order..."
Make sure that every project does not need a project beneath it in that dialog.
About "where to deploy": visual studio does it well by default. If you're in debug, it will output to the debug folder of your solution, likewise for release.
HTH.
Since the suggested way of storing plugins in MS CRM is via the CRM database, I figured it's about time to do something about the method I'm currently using, which is storing the DLLs on the disk.
The trouble however is that I don't know how to embed all the other various bits that are needed by the DLL: the localization resource files (which are kept in another folder) and some referenced DLLs from the latest SDK (which had to be manually placed in the bin\assembly folder). At this point, I'm not even entirely sure this is possible.
So far I've tried to solve the localization problem by changing the build action on the resource files to "Content" or "Resource" and tested this solution (still keeping the location on-disk, but without the added localization folder). This didn't work: when I purposely generated a validation error in one of the plugins, I got the default language message (English) despite having a different language selected in the CRM.
I've faced a similar problem when trying to add some of the referenced DLL files (namely the new SDK DLLs: xrm.portal, xrm.portal.files and xrm.client). When I tried to store the plugin in the database (skipping for a moment the localization issue), I got a CRM error saying it cannot find the XRM.Client assembly or one of it's dependencies. I know I could use ILMerge to put the whole thing together, but I've got a gut feeling telling me this isn't really a good idea.
Any hints or suggestions on this issue would be great.
We always ILMerge our plugins and have had no issues with that. We don't merge in the SDK dlls, because those will already be GACed on the target server.
We don't really do localization inside our plugin dlls, though, so I think what you may have to do is, if your current resource manager is file based, to make it assembly based and just load up the necessary resources from that.
I have a set of helpers that are bundled in an external assembly that I use for most of my implementations. I will deploy this to the bin folder and leave it at that. I've never tried ILMerge myself, but it seems like an interesting concept.
Simply drop the DLLs in the folder CRMWeb\Bin