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.
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 hava a quite complex solution, containing 10 projects aside from Test projects.
It is a network of distributed applications & services that communicate using remoting; therefore having the proper referenced assemblies (& versions) is crucial. That's why I want the whole thing to be compiled and schrink-wrapped in ONE build.
One of the applications is a demo/analysis-tool that runs a subprocess of another - much bigger - application based on the user's input and displays the results; That way engineers have a tool to help tweak their settings for "the big computation". Obviously that subprocess is contained in another assembly, and a big part of te results presented to the engineers is generated by
#if ENABLE_TRACE_MATCHING
Trace.WriteLine("Some engineering output");
#endif
My problem is that Conditional Compilation Symbols in the project settings are limited to that project's assembly, and do not propagate over referenced assemblies.
How can I configure my build in such a way that all projects will be built without ENABLE_TRACE_MATCHING being defined, except for the one debug/analysis-app project where all referenced projects/assemblies must be compiled with ENABLE_TRACE_MATCHING being defined
I also cannot replace #if ENABLE_TRACE_MATCHING by #if DEBUG, since that would enable a whole lot of different output our engineers wouldn't know how to handle.
Thanks in advance.
PS: If you think my code smells, then I agree. Additionally: It's mostly not my code ;)
You need to learn more about Microsoft Build, which is an out-of-the-box Microsoft .NET tool present in any framework's installation.
Using MSBuild you can define these "symbols" (properties) and a batch of commands (targets).
That's you can create a MSBuild script that imports default Visual Studio targets from all projects in your solution, and declare in the script these properties ("symbols").
In fact, the property to set such symbols already exists: "DefineConstants".
So, since you have it, you can have that MSBuild script that provides that property value, re-declaring it there, so, ALL MSBuild targets will be knowing about these symbols.
EDIT:
Check this other question too:
msbuild, defining Conditional Compilation Symbols
I have a library that is meant to be used by many websites. The way I am doing it now is in the library's properties, I set the "Post-build event command line" to: copy "$(TargetPath)" "$(SolutionDir)\MyWebsite\bin\$(TargetFileName)"
Every time I want a new website to use the shared library, I add a new line like this: copy "$(TargetPath)" "$(SolutionDir)\MyWebsite2\bin\$(TargetFileName)"
Is there an easy or better way to do this besides using the GAC?
In my opinion your problem here is a lack of control about how this library is produced and used by other projects. If I were you (which I'm not :) I'd set about developing the library through a unit test co-project where new functionality can be developed and tested independently. Once that functionality has been implemented and tested to be working within your unit test parameters manually copy the assembly into a "library" folder of the web project that the required the extension of the library in the first place (this folder holds all your compiled assemblies used by that project).
Even better would be to maintain a version system in which you tag the new version of the library so as to keep track of the exact source revision that it's using.
The reason I suggest what may seem like a cumbersome methodology of working is that your current practice makes your existing websites quite brittle as a change made in the library for one site may in fact break one of the other sites... and as the amount of sites you have increases you can't be forever retro testing new versions of the shared library against the existing sites.
It's also for these reasons that I don't recommend using the GAC either.
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.
At the company I work for we have a "Utility" project that is referenced by pretty much ever application we build. It's got lots of things like NullHelpers, ConfigSettingHelpers, Common ExtensionMethods etc.
The way we work is that when we want to make a new project, we get the latest version of the project from source control add it to the solution and then reference the project from any new projects that get added to the solution.
This has worked ok, however there have been a couple of instances where people have made "breaking changes" to the common project, which works for them, but doesn't work for others.
I've been thinking that rather than adding the common library as a project reference perhaps we should start developing the common library as a standalone dll and publish different versions and target a particular version for a particular project so that changes can be made without any risk to other projects using the common library.
Having said all that I'm interested to see how others reference or use their common libraries.
That's exactly what we're doing. We have a Utility project which has some non project specific useful functions. We increase the version manually (minor), build the project in Release version, sign it and put it to a shared location.
People then use the specific version of the library.
If some useful methods are implemented in some specific projects which could find their way into main Utility project, we put the to a special helper class in the project, and mark them as a possible Utility candidate (simple //TODO). At the end of the project, we review the candidates and if they stick, we move them to the main library.
Breaking changes are a no-no and we mark methods and classes as [Obsolete] if needed.
But, it doesn't really matter because we increase the version on every publish.
Hope this helps.
We use branching in source control; everyone uses the head branch until they make a release. When they branch the release, they'll branch the common utilities project as well.
Additionally, our utilities project has its own unit tests. That way, other teams can know if they would break the build for other teams.
Of course, we still have problems like you mention occasionally. But when one team checks in a change that breaks another team's build, it usually means the contract for that method/object has been broken somewhere. We look at these as opportunities to improve the design of the common utilities project... or at least to write more unit tests :/
I've had the EXACT same issue!
I used to use project references, but it all seems to go bad, when as you say, you have many projects referencing it.
I now compile to a DLL, and set the CopyLocal property for the DLL reference to false after the first build (otherwise I find it can override sub projects and just become a mess).
I guess in theory it should probably be GAC'ed, but if its a problem that is changing a lot (as mine is) this can become problematic..