So I've been writing a source generator, got it working (apart from this issue) and then discovered this problem which I tried all evening to solve, and am now thinking maybe it's not possible.
I have a project like this:
Project: MyProject
Nuget Package: MySourceGenerator
Project: ChildProject
Child project has a IMyInterface type, and because MyProject references ChildProject, it can also access IMyInterface.
MyProject is the uppermost project, and it's doing source generation based upon some method calls in Asp.Net startup, so I want to keep the reference to my source generator within this project.
My problem is this:
During source generation I can find TypeSymbols for the interface, but I can't find InterfaceDeclarationSyntax's. If the interface is in the uppermost project it can find them, but if it's in a child project then it can't.
Calling ISymbol.DeclarationSyntaxes returns 0 items.
I need this DeclarationSyntax because I need to view the available methods, so I can source generate a class that implements this interface.
I also can't move the interface to the parent project, because other child projects depend on this type.
Is it impossible? It's annoying as apart from this one issue, my source generator was working great. But this will make it unusable for a lot of projects!
Related
I've written a library of expression-tree-related test objects (for the types in System.Linq.Expressions), which I use in tests for ExpressionTreeToString.
The library is in two .NET Standard class library projects within the solution:
ExpressionTreeTestObjects -- expressions generated via the C# compiler and by calling the expression tree factory methods
ExpressionTreeTestObjects.VB -- expressions generated by the VB.NET compiler
ExpressionTreeTestObjects also exposes the main entry point for getting the list of objects (via reflection over the assemblies in the current domain).
I want to publish both DLLs as a single NuGet package.
Where should I put the NuGet package information?
The obvious choice (to my mind) is in ExpressionTreeTestObjects. But how can there be a reference there to ExpressionTreeTestObjects.VB, when ExpressionTreeTestObjects.VB also depends on ExpressionTreeTestObjects? Isn't this a cyclical build dependency?
I suppose an alternative would be to separate code which generates the expression tree objects, from the main entry point code; and put the entry code in a third project (ExpressionTreeTestObjects.Loader) which would reference both original projects. The package information would then go on that third project.
But adding a separate project feels like it should be unnecessary.
I've included the package information in the ExpressionTreeTestObjects.VB project, as can be seen here.
TL:DR How do I reference an assembly only in a class library rather than both the library and the calling project?
I am building a utility library in C# in order to promote code reuse. In this instance, I am wanting to do something things with a TFS server and need to reference several assemblies from the TFS side of things:
Microsoft.TeamFoundation.Client
Microsoft.VersionControl.Client
Microsoft.WorkItemTracking.Client
I include these references in the class library called, say, Utility. I then proceed to wrap objects in those assemblies in helper objects. There are no errors, intellisense works correctly, and so forth.
When I want to use that class library in another project inside the same solution, say, TestCLI, I add a reference to the Utility project by selecting the project from the solution references tab. I can then use the Utility classes without issue, until I go to build.
When I build the solution, it throws an error such as:
The type 'Microsoft.TeamFoundation.VersionControl.Client.BranchObject' is defined in an assembly that is not referenced. You must add a reference to assembly 'Microsoft.TeamFoundation.VersionControl.Client, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
In the past, I have worked around this issue by adding the same references to the calling project (TestCLI) in addition to the class library (Utility). I feel that this is defeating one of the purposes of having a class library and that I've missed a step in order to not have to worry about library references in my calling project.
Is there some way to resolve these dependencies without including the references in both the class library and the calling project? Am I structuring my solutions incorrectly? Am I thinking about class libraries in the incorrect manner?
The references are required because you are exposing objects from the other libraries, and then to use these classes the final program needs the references.
To avoid this you must hide the external objects, through a wrapper, a copy of the class or anything else, it depends primarily on what and why you are exposing those objects.
So XNA 4.0 is being a pain in the butt and selectively not recognizing classes.
I have two projects in my solution, 2DRPGLibrary and Avalon. A class in Avalon, named GamePlayScreen, is trying to reference 2 classes in 2DRGLibrary: World and WorldBuilder.
However, WorldBuilder gives me the annoying "Type or namespace X could not be found" error. I've included a reference to 2DRPGLibrary in Avalon, and World doesn't produce an error. It's only tripping over WorldBuilder.
Help?
EDIT: The only thing that seems relevant is that the 2DRPGLibrary has a Client target class when it should be v4.0 instead. There doesn't seem to be a way to fix this, though, because it doesn't have a .csproj file like Avalon...thoughts?
In my opinion, the reason could be that the implementation of WorldBuilder is using some classes or libraries that Avalon project doesn't have reference to. And these classes or libraries are not registered on the GAC (Global Assembly Cache).
For example: 2DRGLibrary has reference to library A contained in the A.dll file under that project, WorldBuilding uses some classes of A library for its implementation while World doesn't use any. Then Avalon has reference to 2DRGLibrary and use WorldBuilding but doesn't have a reference to library A.
Just check your referencing on both projects to make sure that the above situation is not present then you should be ok.
From a solution, which I made in Visual Studio 2013, I want to transfer a method to a DLL (class library project).
When I paste the method in the DLL project, it doesn't recognize parts of the code and it's showing this error`:
"are you missing a using directive or an assembly reference?"
Because of that, the DLL can't be built. I am assuming, that a certain reference to the solution is required, but I am not sure how to proceed.
I know how to add a reference from a solution to a DLL, but I'm not sure how it's done the other way around or even if it's possible.
You can't add reference to EXE from class library (assuming EXE uses that class library) as it will introduce circular reference.
Usually you need to refactor all dependencies so class library either have them all or allow application to inject dependencies from EXE/other clients. In later case class library needs to define base classes/interfaces to allow such injection.
Yes, you need to restore the same references that the original project uses, if they are used in the code you want to move.
If you need to do this by hand (i.e. without tools like ReSharper):
Move the code to the new assembly.
For each namespace or type giving the error, find it in the Object Browser.
Locate the assembly containing that namespace and type, and add a reference to that assembly in your new project.
You may also have to add a Project Reference to the original project.
Honestly, I can't word my question any better without describing it.
I have a base project (with all its glory, dlls, resources etc) which is a CMS.
I need to use this project as a base for othe custom bake projects.
This base project is to be maintained and updated among all custom bake projects.
I use subversion (Collabnet and Tortise SVN)
I have two questions:
1 - Can I use subversion to share the base project among other projects
What I mean here is can I "Checkout" the base project into another "Checked Out" project and have both update and commit seperatley. So, to paint a picture, let's say I am working on a custom project and I modify the core/base prject in some way (which I know will suit the others) can I then commit those changes and upon doing so when I update the base project in the other "Checked out" resources will it pull the changes? In short, I would like not to have to manually deploy updated core files whenever I make changes into each seperate project.
2 - If I create a custom file (let's say an webcontrol or aspx page etc) can I have it compile seperatley from the base project
Another tricky one to explain. When I publish my web application it creates DLLs based on the namespaces of projects attached to it. So I may have a number of DLLs including the "Website's" namespace DLL, which could simply be website. I want to be able to make a seperate, custom, control which does not compile into those DLLs as the custom files should not rely on those DLLS to run. Is it as simple to set a seperate namespace for those files like CustomFiles.ProjectName for example?
Think of the whole idea as adding modules to the .NET project, I don't want the module's code in any of the core DLLs but I do need for module to be able to access the core dlls.
(There is no need for the core project to access the module code as it should be one way only in theory, though I reckon it woould not be possible anyway without using JSON/SOAP or something like that, maybe I am wrong.)
I want to create a pluggable environment much like that of Joomla/Wordpress as since PHP generally doesn't have to be compiled first I see this is the reason why all this is possible/easy. The idea is to allow pluggable themes, modules etc etc.
(I haven't tried simply adding .NET themes after compile/publish but I am assuming this is possible anyway? OR does the compiler need to reference items in the files?)
UPDATE (16/05/2010):
I posted a similar question with a little more detail for question 2 on Experts-Exchange. I don't want to post all that info here as it just will be too messy but it explains question 2 in greater detail.
For your first question, you want to use svn externals. More details can be found here: http://svnbook.red-bean.com/en/1.0/ch07s03.html
For your second question, you need to create a seperate assembly and the easiest way is to create a new project within your solution. You can't have a single project emit 2 dll's (that I know of)
For your first question:
If the base project is a library then there is nothing stopping you from creating the following directory structure on your SVN:
Base project
Cool project nr 1
Cool project nr 2
All projects built on the Base project will include a relative reference and then everybody can checkout his Cool project X and the Base project and work on them. Checking-in changes for Base project will allow everybody else to see them by updating their Base project image. Advantage: only one SVN trunk required.
For your second question :
I tried my best, but I can't understand what you're asking :).