I have added some 'StatementSyntax' into MethodDeclarationSyntax and I saved that to real Solution. When I opened the solution with VS it doesn't run because I must add some references from other projects in my solution and from .Net.I want to know can I find with roslyn that which reference and using is needed to add to project and c# file and how add these references programmatically if yes how?
Related
I am adding one dll reference to my project. Whenever I modify the dll, I copy the dll the same folder overwriting the old one. But my compiler starts giving errors on the dll methods. Every time I have to remove the dll reference from the project and re-add the reference to build it.
My question is, why I need to remove and add reference every time? .NET should take the new dll automatically?
As others have stated, this appears to be a versioning issue. An alternative to adding the project to your solution (if you don't want it in there for some reason, or you have a requirement to reference the dll directly) is to modify your reference so that it doesn't look for a specific version.
Find the reference to the built assembly in the 'References' project folder
Right click on the reference
Change 'Specific Version' to false
hth
If you have one project depending on the other, put them in the same solution and add the dependant project as a "Project Reference" rather than referencing the DLL directly.
Alternatively, if you want to use an assembly in multiple places, you can create a NuGet package. You can place these in either public or private feeds - and then add the dependency using NuGet.
If you do either of these the dependency will be managed for you.
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".
While doing some refactoring of our projects and solution files, i have separated some .sln files to contain less projects.
Occasionally i need to reference some projects from outside the scope of the current .sln file.
For example, my initial state was this:
SOLUTION A
PROJ A
PROJ B
After refactoring it would look like this:
SOLUTION A_NEW
PROJ A
SOLUTION B_NEW
PROJ B
My question is -- Is it possible to add a ProjectReference node to a project that is not defined in the same VS solution? (in my case, having PROJ A have a project reference to PROJ B).
Also, if it is possible, is that recommended?
I know that this is not possible from the VS IDE, only by editing the .csproj file manually.
You can't do this. A project reference includes an identifying GUID for the referenced project, which is maintained in the solution file in order to track solution build options and dependencies. If you try to reference a project that is not in the solution, Visual Studio will complain.
You can add a file reference to the assembly produced by a project that's not in the solution, of course.
UPDATE: Since this got downvoted, I'll refine my answer.
Though it's technically possible to craft a project file that references another project outside the same solution, Visual Studio won't help you to do it easily. One very good reason why it's a bad idea to do this (that I've observed) is that whatever Solution Configuration and Platform you're building (the referencing project) will be ignored if MSBuild decides to build the referenced project - the default Configuration and Platform specified in that referenced project file will be used instead. Thus you may end up with a mixture of binary types in different folders.
Temporarily add the project to the solution, add a reference to it, unload the project that now has a reference added to it, remove the referenced project, reload the project with the reference.
If you don't unload the project then the reference will be automatically removed by Visual Studio when the referenced project is removed.
As you can probably tell, Visual Studios not designed to do this and you'd be better defining a build order for the solutions and use assembly references instead.
You can definitely add a project to a solution A that is in solution B. There is not any problem with that. From my experience, it's not something that I usually have done or do, but sometimes need to. This can be especially true on large projects where you need different nodes of your architecture to reuse same code base.
Hope this helps.
I am getting an error back from a DLL saying it cannot create an instance of one of classes in my solution because it cannot find the assembly file.
If I am debugging a solution, do I need to put a copy of certain assembly files in other locations?
EDIT:
In my compiled solution all the DLLs (including the proprietary ones) all go in the app directory and it works fine. But I am trying to work out where the files should do in order to debug the solution.
Put the assembly in question in 1) the same directory, or 2) in the GAC, or 3) use AssemblyBinding to define the specific path that the .NET framework.
MSDN link: using AssemblyBinding to define the referenced assembly path
I think you have forgotten to add reference of the assembly to the project.
Add the reference, and try again.
Read more here -> http://msdn.microsoft.com/en-us/library/7314433t%28VS.80%29.aspx
If they are in your references list, try right-clicking the problem reference in the solution explorer and selecting "properties". There is one property called copy local. Make sure that is true. Then when you build, a copy of that dll will be in your bin folder.
You can add an event handler to AssemblyResolve to find out which library it tries to load. Some sample code and ideas can be get from this question.
Update
To find out, what is the best place for your project you should take a look into How the Runtime Locates Assemblies guide. Also to get a live view about where the framework searches for your needed dll you can use ProcessMonitor to see where it tries to catch it.
Why one project (exe) does not see the namespace of another project (dll) in the same solution?
You need to add a reference from the using project to the DLL first.
Select Project|Add Reference, Projects Tab.
A "solution" in Visual Studio is a collection of projects. Each project is independent of all the others. The solution is just a convenient way of organizing projects and opening them all together.
If one project is going to use the public objects defined in another project, then it must be compiled with a reference to the other project. This is true whether the projects are part of a single solution or not.
To signal to Visual Studio that the EXE must be compiled with a reference to the DLL, you must add the DLL to the EXE's list of references in the Solution Explorer.
You need to add a reference to the DLL.
Right-click the EXE project, click Add Reference, go to the Projects tab, and select the DLL.
Also, make sure that the classes in the DLL are public.
Sounds like you need to add a reference to the dll
Right click on the project --> Add Reference