I want to extract custom attributes from source code from different .CS files. I have list of files .
Scenario is that i have Project A which reads files of Project B. It has to extract all attributes used in Project B.
My question is that how can i do that without using Reflection.
Reflection deals with assemblies but i have source code.
Using Roslyn would be over kill?
what approaches are there?
I had another option to Compile using MSBuild but for large scale projects it would not be feasable due to heavy dependencies. and it seems not a good way to build application and then going for its assemblies
i just want to have some sort of thing that tells me what attribute was on what class and possible a UML diagram of relations of that classes.
Please give your suggestions
You could use NRefactory: https://github.com/icsharpcode/nrefactory (also available as a NuGet package)
Related
I have been given a folder than contains many solutions in subfolders along with their code. Each solution builds a PrinterDriver.dll. What I am trying to do is create a master solution that I can add all the projects into and then they will all compile every time.
I cannot at the moment do this, when I add each to the master I get an alert telling me that a project of that name already exists. what is the best way to do this?
I'd urge you not to create a master solution containing projects with the same name, that will end up a mess... You'll have to change assembly names and namespaces and as you've found you end up with dozens of namespace ambiguity errors.
all the projects ... will all compile every time
If the aim is just to compile all the projects at once, every time, then simply write a MSBUILD script that uses all the project files to compile outputs.
Eg: Compiling a .vbproj or .csproj project file without Visual Studio
If you do want a master solution it will require surgery. One way would be to create interfaces (or abstract classes) that reflect the method signatures of each class in every project and using IoC load different implementation classes depending on the target.
Warning: Be wary about changing namespaces, while prefixing namespaces with a unique name may sound simple. You have to be aware of the impact especially on code library's (like Printer.DLL) that other projects reference.
I have attached the sample in the following location
https://onedrive.live.com/redir?resid=D3615D07F8A53977!3971&authkey=!AJ1EjQrQbnDA9sw&ithint=file%2czip
And I have the following problems in the above sample.
When changing IEnumerable to IQueryable using AsQuerable method, the MissingRuntimeArtifactException is thrown. This problem has been solved when using the below line in rd.xml file in App1
<Namespace Name="System.Linq" Dynamic ="Required All" Serialize="Required All" XmlSerializer="Required All" />
My question is how to include rd.xml file in CustomButton class library? If I add manually by adding new xml file in CustomButton, its not working when I run App1 with CustomButton dll. How to resolve this?
While using Expressions in IQueryable extension method(Count()) the same exception has been thrown. Please suggest any solution for this issue.
Regards,
Antony Raj
If you use the template for Class Library (Universal Windows) it will do two things that you'll find beneficial.
It will generate a .rd.xml template
At build time, it will embed this xml file into your library as a resource
When compiling applications to Native code the .Net Native toolss (ilc.exe) will look for all files in the project that match *.rd.xml and all resources in libraries. Embedding this way makes deployment of your library much simpler.
If you'd prefer to not embed this asset it'll be up to you to make sure the file lives next to your assembly via whatever deployment mechanism you prefer. (Sometimes it's included in Nuget package and just copied around.)
Also, I'd highly advise against using the directive you have above. In particular the portions of it that are Serialize="Required All" and XmlSerialize="Required All". Adding those to the directive will great bloat the amount of serialization code generated and it's pretty unlikely you actually need to XmlSerialize ALL of the types in System.Linq.
I would like to use MS VS2012's add as link functionality, meant for files, but instead for a certain block of code.
I've got a solution with lots of projects. I am creating a unit testing project that will house all the algorithms that exist in the other projects in the solution. I can copy over all the algorithms I want to test into a file in the new unit testing project, however I am also looking for a way to automatically update the code in the test file if say the code in the other projects updates. It is almost as if I want to create a reference to a code chunk in VS.
If no such functionality exists is there some sort of script I could create that updates the code in the test project every time I build?
EDIT:The reason I can not have testing code within the projects themselves is because the other projects in the solution are .NET Microframework projects and the .NET Microframework does not support the use of c# attributes which are being used with the NUnit testing framework. Hence the reason I can not have any test code within those projects. However, there are some algorithms in the driver files of the .Net MF projects that I would like to be able to test and these algorithms are independent of the project type, so I am looking for a way to keep this code in sync so that if any changes are made to the algorithm within the .Net MF projects the same respective change is made within the unit testing project without the need for manual copying.
EDIT: In the simplest terminology all I am looking for is some sort of script I can run to copy over certain code blocks from one project file to another project file.
I had a very similar problem where different parts of the same source code file were shared between different projects. Here is a fix that worked for me.
Suppose the source file File1.cs contains four methods, two of which are used by ProjA and two are used by ProjB, where ProjA and ProjB are different projects inside a Visual Studio solution.
To keep just one copy of File1.cs, use conditional compile symbols, e.g. PROJ_A and PROJ_B for the two projects. Put the methods used by ProjA under conditional compilation symbol #if PROJ_A and put the methods used by ProjB under conditional compilation symbol #if PROJ_B. Then add File1.cs as linked file to both projects and make sure that corresponding conditional compilation symbols are set on those projects.
If this is what you were looking for, let me know if you get any problems implementing it.
Basically, I developped a small library with some common fonctionnalities that I use in all my projects. For some political reasons, I cannot choose a generic name for that library (including namespace and assembly name). Usually, it must include the name of the enterprise, something like this for the namespace: Enterprise.ProjectName.XXX.YYY.
For the moment, I'm doing a copy of my library, then I'm renaming the namespaces manually with Visual Studio, and finally I'm recompiling the whole thing.
So my question is the following: Is it possible to create a small program that takes an assembly as input, rename all namespaces from MyLibrary.XXX.YYY to Enterprise.ProjectName.XXX.YYY as well as the assembly name?
What are the steps to follow?
[Edit]
Generating the assembly automatically seems to much work. I will use resharper and/or CTRL+ALT+F like I did so far. Thanks for the answers...
You could use Mono's Cecil project to disassemble the assembly, inspect each type, rename or recreate the type with a new namespace, and generate the resulting assembly.
That being said, it might be simpler to use a tool like Resharper which allows you to rename namespaces correctly within the code base.
Some options:
If you are copying the entire source code for your library into your new project, you can use a refactoring tool like Resharper to "Adjust Namespaces". This is a pretty quick and safe refactoring.
If you just need to avoid shipping the internally named assembly, you may be able to use ILMerge to 'hide' the internal assembly during a post-build step. This is viable if it's just a perception issue for the final assembly names in the binary output directory.
Deal with the issue at the political level by describing your internal library as being no different from any other third-party dependency. Then the naming is no longer a problem. This may solve other problems if you're shipping the source code of this library to multiple clients, as it clarifies that you are not giving full ownership of your 'shared' code to each client. Otherwise they could potentially argue that you are not allowed to use that 'shared' code in projects for other clients, since it is clearly owned by them, having their enterprise name in the namespace.
I'm building a tool in managed code (mostly C++/CLI) in two versions, a 'normal user' version and a 'pro' version.
The fact that the core code is identical between the two versions has caused me a little trouble as I want to package the resulting tool as a single assembly (DLL) and I don't want to have to include the .cpp files for the common code in the projects of the two versions of the tools. I'd rather have a project for the common code and a project for each version of the tool and have each version of the tools project depend on the common code and link it in as desired.
In unmanaged C++ I'd do this by placing the common code in a static library and linking both versions of the tool to it. I don't seem to be able to get this to work in C++/CLI. It seems that I'm forced to build the common code into a DLL assembly and that results in more DLL's than I'd like.
So, in summary, I can't work out how to build the common code in one project and link it with each of the final product projects to produce two single DLL assemblies that both include the common code.
I'm probably doing something wrong but I tried to work out how to do this using netmodules and whatever and I just couldn't get it to work. In the end the only way I got it working was to tell the linker to link the build products of the common code assembly rather than the results which works but is a bit of a hack IMHO.
Anyway, does anyone have any suggestions for how I SHOULD be solving this problem?
Edited: I guess I should have mentioned the fact that the assemblies generated are not 100% managed code, they contain a mix of managed and unmanaged code as is, probably, quite common with assemblies produced with C++/CLI...
If you are annoyed at all the DLLs, download ILMerge. I use this to bundle together multiple DLL's into an easy-to-use .EXE for my clients.
If I'm understanding this correctly, you have a solution which contains two projects. One project for the "normal" user and one project for the "pro" user. Visual Studio allows you to add a "link" to another file source from another project. If your "pro" version has the real core code file, and in your "normal" version you add existing -> find the file in the "pro" project, and click the down arrow by the Add button and select "Add as Link". Now you have single file that is literally the same between two projects.
As said, ILmerge is one way. Personally, if you're bundling some exe with a lot of DLLs, I favor Netz.
You could use modules. You can link them into an assembly using the assembly linker, al.exe.
That's the downside of the .Net compilation process, you can't have things like static libraries and the header files that hold them together, everything is held in one big dll file and the only way to share information is to either build a common dll and reference it from other assemblies or to duplicate the code in each dll (possibly by copying/linking .cs files between projects).
Note that the 2nd way will declare different types, even though they have the same name. This will bite you on the ass with stuff like remoting (or anything that requires casting to specific shared interfaces between processes).
Remotesoft Salamander will hook you up. It's basically a native compiler and linker.
When using mono (or cygwin is an option) mkbundle may also be a valid choice.