We setup our assembly references as project references. I am reorganizing source control, moving projects here and there. When I open my solution the project references are broken. I have to remove the references and re-add them. Doing this removes the project reference from all assemblies.
Is there a way to correct the project reference in the solution file without removing and re-adding projects?
I could go into MSBUILD and do it, but there's no unload option for my solution...so that seems like a pain. Any native way to fix this common issue? Since the files are in the same solution, I expect the project references to resolve themselves automatically.
This way I don't have to correct all my references manually.
If you need to do this just only once - Resharper could help you to do this a bit faster.
Whenever it finds broken reference - it will offer option "reference assembly X and use class Z". Probably not the best way cause it still involves manual file plumbing, but this could SLIGHTLY reduce mouse clicks and file tree navigation. Though, you still need to remove wrong reference manually.
Related
Why not keep all projects loaded, how does unloading a project benefit us?
https://msdn.microsoft.com/en-us/library/tt479x1t(v=vs.100).aspx
Prior to the new .NET Core projects, the only way to edit a project file in Visual Studio was by unloading it and then making the changes in the unloaded project file.
When you are building a solution unloaded projects are not building, so build will be faster. Also if you have 40 projects in solution it is just more convenient to unload some of them, which you are not modifying.
When that project is redundant and a new one has been created to replace the old code. Say, it was Proof Of Concept stuff anyway.
To edit something in project file itself.
In some particular cases, when that project has no dependency and will not be at all required in current development. May be, it was creating its own dll to provide some functionality which will not be required now and you have replaced it with better software you got or purchased from internet.
If your current solution is a copy of old solution with a few changes, and this project will not be required currently in the solution but you know that requirements may change and you may have to do something like that in this solution also, then for the time being, you unload it so that rest of the solution loads and works faster. That's why sometimes related projects are unloaded together due to dependency.
Always run a build after unloading a project. You may have to make it work.
I have seen most of the time how developers in order to work on a solution, right click on solution folder in source control, select "Get Latest" and... have tons of problems: solution's projects reference other projects from other solutions, missing references, etc...
Here is the simulated example of something similar we have at work...
Now, imagine you have to work on TicketsSolution, specifically - fix some bugs, make changes with TicketsSolution's Web project. Usually developers right click on TicketsSolution's folder in TFS/VSS (whatever) and select "Get Latest"... and the above mentioned problems hit them right in the face.
Turns out, TicketsSolution also includes such projects as
Common.Solution1.Project1, which may have a reference to Common.Solution2.Project1
Common.Solution1.Project2
WCFServicesLibrary project, which may have a reference to SQLServerProxy project
also, some external 3rd patry DLLs that have been missing or placed somewhere under ROOT but outside the TicketsSolution folder...
In this scenario when you Get Latest for just TicketsSolution folder all those references will be missing,
so it seems the only reasonable way to Get Latest would be right-clicking on JUST the solution file, such as TicketsSolution.sln and getting latest of that file only. Then, opening that TicketsSolution.sln file in Visual Studio would hopefully :) reconstruct all the tree nodes within and beyond the solution folder required by the solution.
Even in this approach references for external DLL libabries will be missed, because VS knows how to reconstruct the folder-tree, but it doesn't include DLLs referenced outside of TicketsSolution folder.
But 90% of developers get latest of the solution folder and having tons of problems.
So, my question is - in this scenario, whould it be correct to include external projects in TicketsSolution solution, or it would be more reasonable to add "lib" folder under TicketsSolution folder and drop the dlls of all those external dependent projects in it, and then, reference them from the solution's projects, instead of reconstruction the entire folder tree with all the dependent projects from upper levels (that may and probably will have their own dependencies and reference problems) ??
Lib folder makes life simpler but introduces other issues in you build hierarchy.
Plus you have to store your libraries in source control which to some people is a no no.
I use a local NuGet feed.
I think the simplest answer to your question though, is to create a .bat file, write the check out calls for the folder s you need to check out for a solution, store in the solution root folder on TFS.
Get the devs to click the bat file to get latest on all of the files for the solution.
Looking to make a Solution/Multiproject Template.
While I'm aware a solution template does not exist, I've been researching/trying with some of success. (Link from here (http://stackoverflow.com/questions/2717110/how-to-create-a-solution-template-in-vs2010) have been a big help.
The only issue I'm facing is that, when creating a project from my template, the solution contains brand-new copies of all of the projects involved. What I require is that only ONE project is made as a fresh copy, and that the other projects in the template should reference already-existing projects.
I've made single project templates that hold the DLL references to other projects (which is fine, but it's not what I need.) I need a multi-project template where all but one project involved reference already existing projects...
How would I go about this?
edit:
I'm also finding that any dbml designer.cs that's added to a project are not included in the newly generated solution/projects. They are copied across, but I then have to manually include them in the project. Why is this, and how do I get araound it?
How about using the Feature Builder Power Tool? http://visualstudiogallery.msdn.microsoft.com/67b720f4-9a50-41cb-86a2-82e33b7c5fc4/
It should give you all the freedom to create whatever logic you want during solution setup...
So I couldn't find a workaround for this issue.
What I have managed to do though is make a decent enough template that should be run once, with all references (being relative) pointing to an outside lib folder.
This means I can use the template on a new machine, copy some dlls to a new lib folder, and then work away from there. Not an ideal solution, but it works...
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 experienced an annoying issue with Visual Studio 2005... sometimes when I rebuild, and even if I do a Rebuild Solution, it will come back with no errors or warnings, but then when I later edit another code file, even without changing it, and rebuild, it will find an error or warning in that other file. Clearly, the earlier Rebuild Solution did not recompile that file! How can I force VS to completely recompile every file?
I've seen this happen before when you have multiple projects in your solution and the references get mixed up.
Say you have four projects in your solution, Common, Business, Data, and UI. Assume that Common is referenced by the other three projects.
What we want is for Common to be a "project reference" from the other three projects - they'll then pick up their copy from the build output directory of Common.
But, sometimes, one of the projects will get it's reference mixed up. Say, in this case, that UI starts referencing the copy of Common in the build output directory of Data. Now, any change that compiles "UI" without also compiling "Data" will result in two, possibly incompatible, versions of "Common" being a dependency of UI.
Another scenario is where the reference is to a binary, such as from a "lib" directory. Then, one of the projects ends up referring to a build output location instead of lib.
I don't know what causes this - but I see it all the time, unfortunately.
The fix is to go through the references of each project and find the one (or more) that point to the wrong place.
It might help to clean the solution prior to rebuilding -- right click on the solution in the Solution Explorer and choose "clean solution" -- this deletes temporary files and is supposed to clear out the bin and obj folders, so everything is rebuilt.
I'm with Guy Starbuck here, but would add that Rebuild Solution is supposed to do a Clean Solution followed by Build Solution, which should, then, have solved your issue to begin with. But VS 2005 can be terrible in this regard. Sometimes it just starts working after several rebuilds. If upgrading to 2008 isn't an option, consider manually clearing the bin folder.
Is this related to the Configuration Manager? There you can select which projects in your solution build. Not sure if this helps.
Depending on the types of warnings it is not possible if I recall correctly.
For example, warning messages for XHTML compliance are ONLY displayed when the file is open. You might check the tolerance settings inside VS to see if you can change it.
This sounds strange - Rebuild should build everything regardless of changes and Build should only build things that have changed.
The behaviour you've described should only happen if you have modified something that is referenced by the unchanged file so that it is now incorrect.