I have a solution with 3 projects. I made it as a test:
1) The WinFormsProject (setted as Main project): It is just a form that throws an exception when clicking a button. Before throwing the exception, it makes some assignations with an object of the class Person (who is in another assembly).
2) The ConsoleProject: It's another assembly with the same idea: it only plays a little with an object of the class Person and then throws an Exception.
3) The AspectTest: it's an assembly which has defined the class Person and an aspect (called LogBoundary) (inherited from OnMethodBoundaryAspect) who logs OnEntry(), OnExit(), OnSuccess() and OnException().
The three assemblies are configured through an "AspectInfo.cs" class to target every method but the "CompileGenerated" ones. So:
[assembly: LogBoundary()]
[assembly: LogBoundary(
AttributeExclude = true,
AttributePriority = 0,
AttributeTargetMemberAttributes = MulticastAttributes.CompilerGenerated)]
The problem is that all methods in the assembly AspectTest are being logged, but the ones in WinFormsProject not. I have no idea why.
Some things to consider:
Every assembly has a reference to postsharp. So every aspect is
being correctly recognized by the compiler.
If I set the ConsoleProject as the Main project, it works
correctly. The problems comes only with WinFormsProject.
WinFormsProject references AspectTests (of course!).
ConsoleProject references AspectTests (of course!).
There is no dependency between WinFormsProject and
ConsoleProject.
Any help would be great, and if you still need some info about this, please ask me (I might forget to tell something).
Thanks!
To introduce the aspects into your code, PostSharp needs to execute during build time after the main compilation step. This means that adding a reference to PostSharp.dll in your project is not enough - the build sequence of the project needs to be modified as well.
PostSharp automatically integrates into the build process when you install the NuGet package. If PostSharp doesn't run during build, then you can try to reinstall the package.
Well, I am a bit ashamed of the reason, but it might pass to anyone, so here's the problem and how I solved it.
The problem was: as I added the postsharp.dll as a reference manually and not with NuGet (because I had no internet on that moment) the references were ok, all compiled as expected, but as said, aspects didn't worked on the Winforms project. Maybe I missed to do something else.
The solution, therefore was so easy as to add postsharp through Nuget. Just that.
Now everything works. If someone has a better idea of the description of the problem, it would be good to know it.
thanks, AlexD.
I have 2 Class Libraries that contain WPF Controls and resources in a Solution. I want to be able to share resources between them at Design-Time so I can actually see what I'm designing. At run-time everything is ok, as I am loading the dlls dynamically.
If I reference each project to each other I get a circular dependency issue
I am using blend & if I add a reference to the DesignTimeResources.xaml, a project reference is added which I don't want.
Any help appreciated.
Create a common project, and have both projects reference it. Then you will not have a circular reference.
If you make the class static, then it is even easier to share data.
The below link demonstrates step by step process to achieve your requirement. I hope this will help you.
Set up the project for design-time debugging
I may not be asking this question correctly as I haven't been able to find a reference here or on Google. I need to modify a class that is in one of my reference DLL's. Will VS look at the reference DLL first or the local file first ? It seems to look at the reference DLL first. Is there a way to tell VS which to look at first ?
Thanks
Clarification - I have a class definition in the reference DLL and also in a local project file. The local project file is the class definition that I need the program to use.
Using an alias on your references, you can specify which of two similarly named classes you are referring to in your code.
This is explained by Jon Skeet here:
What use is the Aliases property of assembly references in Visual Studio 8
Limitations
This will only help you, if you instanciate that class yourself. It is not possible to let a foreign assembly create instances of your own class if there is no dedicated mechanism (i.e. API) for doing so.
Your question is quite vague, but if you use the Fusion Log Viewer FusLogVw.exe (just search for it on your computer) you can see what dlls are loaded and which paths were used to look for it.
This depends on how you setup your reference to the project in question. Visual Studio has 2 concepts of references.
Project to Project
Project to DLL
For the sake of this discussion lets call the main project A and the referenced project B (the class to change is located in B)
If there is a project to project reference from A to B then the build is always against the latest source code. Hence if you change the class definition A will always build against the changed class.
If there is a project to DLL reference from A to B then things are a bit murkier. There are so many possibilities here that it is hard to speculate intelligently what will happen. It may get the updated class, it may not, it may after a second rebuild.
In general though if you have 2 projects in the same solution and one references the other you should always use a project to project reference. The easiest way to guarantee this is to delete the reference, right click select add reference and go through the project route instead of "Browse".
We are doing a project that uses interfaces and Unity to resolve concrete implementations of classes.
My questions is the following: I need to get my dll's all into the same folder otherwise unity will not be able to resolve the interface etc. So according to me I have a couple of options:
1. Add the projects with the implementations as references and let VS copy the files to the output folder (for some reason this just feels like a hack)
2. Change the build location of all my projects to build to the same folder
3. Create a post build event to copy all the files needed to whereever they need to go
I have implemented to second option but this could lead to files in your build folder that should not be there. I am not a big fan of post build events, so I would like to ask from other people using Unity what they found to be the best solution for them.
Thanks in advance
The first approach sounds like the right one to me. Your project does depend on the implementation libraries; it doesn't express that dependency directly in code, but it requires them, so it seems reasonable to add a reference to them.
This is basically the same situation as where you've got three projects, where project A depends on project B, which depends on project C - you need to explicitly add project C as a reference within project A. Visual Studio doesn't work out transitive dependencies for you (at least it didn't the last time I checked).
My C# project - we'll call it the SuperUI - used to make use of a class from an external assembly. Now it doesn't, but the compiler won't let me build the project without the assembly reference in place. Let me elaborate.
This project used to throw and catch a custom exception class - the SuperException - which was derived from the standard System.Exception and lived in a separate, precompiled assembly, SuperAssembly.DLL, which I referenced.
Eventually, I decided this was a pointless exercise and replaced all SuperExceptions with a System.SuitableStandardException in each case. I removed the reference to SuperException.DLL, but am now met with the following on trying to compile the project:
The type 'SuperException' is defined in an assembly that is not referenced. You must add a reference to assembly 'SuperException, Version=1.1.0.0 (...)'
The source file referenced by the error doesn't seem relevant; it's the project namespace that gets highlighted in the IDE.
Now, here's the thing:
All uses of SuperException have been eliminated from the project's code.
Compared to another project that compiles fine without a reference to SuperException.DLL, I only reference one more assembly - and that references nothing that my project doesn't reference itself. While it's possible that any of these dependencies could throw SuperExceptions, I'm only catching the base Exception class and in any case... the other project builds fine!
I've done Visual Studio's "Clean Solution" and cleared everything out by hand, many times.
It's not the end of the world to include this reference, I just don't see why it's necessary any more. Nrrrgg. Any pointers welcome!
It's likely a transitive reference, where some type method call returns an instance of SuperException boxed ("downcast") as e.g. Exception, but from inspecting the code in the transitively included code, i.e. code from your external method calls, the compiler knows that you need to be able to have information about that type at some point.
Resharper would tell you where it's the case that you need to add a reference, and you could use Lütz Roeder's aka RedGate's Reflector to scan compiled IL for a reference to this type in two ways: 1) use the search-facility, 2) open each public type you're using and for that one which requires the "ghost" assembly, it will ask you to specify its location.
This most often happends to me when I reference Castle.Windsor but not Castle.MicroKernel. :p
Exit Visual Studio
Delete the bin and obj Folders in your solution directory
Restart and see what happens
I agree with the other comments here.. There is a reference, in plain text somewhere !
I have had similar problems in the past where searching through the project files returned nothing, turns out it was in some other file that wasn't automatically picked up in the search.
I don't think that creating a new project is the solution here.. You need to be positive that NONE of the references in your dependency tree use SuperException.. NONE
I have never experienced this to the point where I have needed to literally wipe the project, I have always found the reference somewhere. Ensure you are searching every file.
EDIT:
Just a point to add, if the location pointed to by the error seems random, that can often mean there is a mismatch between the compiled source and the source code file.. Is this a ASP.NET application? I have had it before where the compiled DLL's haven't been replaced on a rebuild in the ASP.NET temp folder causing things to get.. Interesting when debugging :)
I don't think this is a code issue. What I can see happening is that one of your existing references probably rely on that type in their own types which you are probably creating in your application.
If that is the case you do need that reference even if you don't explicitly use the type and even though the other referenced assembly has its own reference. You sometimes get that issue with 3rd party components which need references to types that you haven't referenced. The compiler is obviously seeing something in one of your existing referenced assemblies and is expecting you to referenced the dependent one.
Since it's a compiler error, there must be a reference or use of SuperException somewhere in the project.
Do a find/replace in the entire project or solution for that type and remove every reference (it's possible you already did this).
If you reference any types that inherits from SuperException (even if the type defined in another assembly), you need a reference to the assembly that SuperException is defined in.
Take the line that the compiler is showing the error on and start tracing the inheritance tree of the objects used on that line, you might find the source of it that way.
Thanks for your answers so far. I've tried every suggestion (except one) to no avail.
The suggestion I haven't tried is to create a new project and add all my stuff to it, the thought of which really tests my will to live. ;) I may try this tomorrow if I can be bothered. Thanks again.
There is really nothing very mysterious about VS projects nowadays - it's all text files, etc. SOMETHING must reference that class/dll, and that something must be part of your project.
Have you really grep'd or findstr'd the whole solution tree, every single file, for a reference to that exception?
This sounds pretty strange. Here's what I would check next:
Check that there's nothing lingering in your Properties/AssemblyInfo.cs file.
Check that there's nothing lingering in your SuperUI.csproj file.
Delete all references and re-add them.
Try creating a new project, and adding all your classes to it.
grep your project folder. It could be a hidden reference in your project, or a project that your project references. Cleanse with Notepad if needed.
If you reference any types that inherits from SuperException (even if the type defined in another assembly), you need a reference to the assembly that SuperException is defined in.
Seconded on that.
You might not be referencing SuperException, but you might be referencing SpecializedSuperException, which is derived from, or somehow otherwise uses SuperException - your grep of the project for SuperException won't be catching it though.
Try have a hack with the trial of NDepend
This is where tools like Resharper really pay off -- a simple Find Usages usually tells me of such "ghost dependencies" several times.
Maybe you could go to your definition of the SuperException class and try to Find All References(). You might also want to investigate if the assembly SuperException is has a circular dependency on your main assembly (e.g., main assembly depends on exception assembly depends on main assembly...).
I’ve had a very similar assembly reference issue that was happening when my C# library had a dependent C++/CLI assembly.
The problem that was I was inheriting a public class from that C++/CLI assembly in my C# assembly library. That meant that the inheritance chain was spanning across multiple assemblies.
I was hoping that any client would be smart enough to indirectly load the C++/CLI assembly any time the C# library needed it, but that was not the case even at compile time.
I got rid of this problem by breaking the inheritance between the classes that were spanning across those two assembly libraries and using aggregation instead.
My client was finally happy and did not require the C++/CLI assembly as a dependency anymore.
In your word you would probably have to make sure that SuitableStandardException does not inherit from SuperException in order to eliminate the SuperException.DLL as a reference.
Use encapsulation instead of inheritance and create a SuperException data member in your new SuitableStandardException.
If that does not solve it, you might have more classes spanning inheritance across some assemblies, in your case SuperAssembly.DLL and superException.dll.
If you can't find all of them try this trick:
Make all your public members and classes in SuperAssembly.DLL internal.
In the SuperAssembly.DLL make friends with SuperException.DLL:
[assembly:InternalsVisibleTo("SuperException, PublicKey=0024000004800000....)]
Make sure that they build and remove the SuperAssembly.DLL reference from any client that already references SuperException.DLL.
grep -R SuperException * in the base of your project (get grep from somewhere first) just to be sure.