Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
I'm trying to figure out how to manage our main Visual Studio solution.
In the solution we have to manage C++/CLI projects, C++ native projects, C# projects, external dependencies (compiled C# assemblies with their own dependencies) managed by other teams and frequently updated (together with their dependencies).
Every type of project can be a dependency for each other (except C# or C++ native of course).
Some C# projects have dependencies on external DLLs which can require some other DLLs to work properly.
Until now we have used post-build-steps to copy references to each project's output directory (additional dependencies for C# libraries compiled externally and required C++ DLLs).
We would like to automate this process. Projects are many, and external DLLs are often managed by other teams (sometimes they add more and more dependencies) and we would like every change made by them to be automatically reflected on our main project.
Is there a tool, a best practice for batch files, or something not to lose ourselves in this dependency hell and just make a svn update and a little configuration effort every time a new project is included in a solution?
One of my problems is if I have a C# project1.dll which requires C# project1a.dll and C# project 1b.dll, if my C# project2 requires project1.dll I would prefer not to add project1a.dll and project1b.dll to project2 references but I would like to find it in my output folder (this is because project1a is managed by another team and day by day could require project1x.dll to work).
How did you solve this requirement?
Here's a Microsoft Connect suggestion requesting simular features, (this one's mine actually). Unfortunatly references do not update with your solution build configurations very well. It forces you to split up your project and maintain redundant project/solutions in some cases (like binary references).
If you can build all of your project from source then you have nothing to worry about, but this is rare, and you can see in the connect suggestion, it's not possiable for some system dependencies.
Here's a blog post for some heavy duty for build customization.
You could try using NuGet and hosting your own package feed?
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I have a relatively comprehensive solution that contains about 20 projects. One of the projects is "Utils", which I would like to have shared for other solutions. Unfortunately, if I added this project to another solution as a linked project, then this project didn't upload me to Git for this solution, so then teamwork is not possible. Therefore, I am looking for a solution to achieve that I can share the source codes of this project between the individual solutions. I use VS2019 and as a Git repository xxx.visualstudio.com. Thanks for the advice.
If doing a nuget package is not a solution for you because it add too much friction (even if you could also give access to the util repository), and that you want to be able to update the "Utils" source directly from the sln file, then the solution for you is to use Git submodules.
From the documentation:
It often happens that while working on one project, you need to use another project from within it. Perhaps it’s a library that a third party developed or that you’re developing separately and using in multiple parent projects. A common issue arises in these scenarios: you want to be able to treat the two projects as separate yet still be able to use one from within the other.
You will have to create a repository for the "Utils" code and include it in the other(s) repositories as submodules.
But Visual Studio still no support it...
It's not crippling because you could still use it from the command line or from an external git GUI that support it (like GitExtensions for example).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I'm writing plugins (i.e. .Net 4 libraries with a special entry point) for a .Net framework application, but I also want to expose the functionality as self-contained CLI executable.
The current directory layout looks like this:
Directory.build.props // shared configuration, e.g. author name, project name
FooPlugin/FooPlugin.cs
Foo/FooPlugin/FooPlugin.csproj
Foo/FooLib/FooLib.cs
Foo/FooLib/FooLib.csproj
Foo/FooExe/FooExe.cs
Foo/FooExe/FooExe.csproj
Bar/BarPlugin/…
FooLib is a .Net Standard 2.0 library with the entire functionality in FooLib.cs, FooPlugin is a .Net 4.8 library with the entry point for the plugin FooPlugin.cs and FooExe is a .Net Core executable with a CLI wrapper for FooLib in FooExe.cs. So far, so good.
I have two major problems with this approach:
FooPlugin depends on several application specific Windows-only assemblies so I can't just dotnet build from the root directory, because msbuild tries to build FooPlugin as well and I haven't figured out how to conditionally exclude subprojects from the solution file.
Each plugin (and CLI app) has two files (FooPlugin.dll and FooLib.dll / FooExe.dll and FooLib.dll) which in itself isn't that bad, but my users ignore FooLib.dlland then complain.ILMerge` looks promising, but its configuration is a lot more complicated than the entire remaining build configuration combined.
In CMake, I'd just write
add_library(FooLib STATIC FooLib.cpp)
add_library(FooPlugin SHARED FooPlugin.cpp)
target_link_libraries(FooPlugin PRIVATE FooLib)
add_executable(FooExe SHARED FooExe.cpp)
target_link_libraries(FooExe PRIVATE FooLib)
and have FooLib merged into both FooPlugin.dll and FooExe.exe.
I already thought about putting symlinks to the (few) source files in FooLib into FooPlugin and FooExe, but the support for symlinks on Windows isn't that good yet.
Can I define targets in msbuild to be merged into assemblies automatically?
A fairly trivial solution would be to just create multiple solution files that each contain some of the projects.
For a more competent solution I would take a look at Cake or Fake. I have used neither, but they seem to be the most popular build systems on the .net platform.
You can also use the target switch for msBuild to build a specific project in a solution.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I want an AnyCPU dll for PCRE for C#. In the currently available PCRE.NET we can make it either 32 bit or 64 due to its C++ dependencies. Is there an implementation that can be truly MSIL, like using DllImport with an if else for selecting the correct source based on the application. If not, Can anyone guide as to how to make one. Any help would be appreciated
Disclaimer: I'm the author of PCRE.NET.
PCRE.NET is an AnyCPU assembly, which ships both an x86 and an x64 version of the native library inside. It will choose the correct one at runtime. It won't run or ARM or any other architecture though.
If you want some details, the main MSIL assembly contains two mixed-mode assemblies in its resources. At runtime, it will choose the correct one, unpack it into %TEMP%, then load and use it.
You need to have the MSVC 2015 redistributable package installed though, because the C++/CLI part depends on it.
To make the library compatible with .NET 4, you'll have to replace some interfaces like IReadOnlyList<T> with IList<T>, Volatile.Write with Thread.VolatileWrite etc.
As for this line:
System::Threading::Volatile::Write(_calloutInfoByPatternPosition, dict);
You could replace it with:
#undef MemoryBarrier
System::Threading::Thread::MemoryBarrier();
_calloutInfoByPatternPosition = dict;
Not that pretty, but works.
Last but not least, make sure to run the build script (build/Build.Bat) to compile the library, as it will execute the steps required to embed the mixed-mode assemblies inside PCRE.NET.dll.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I need to create some functionality in our large C# software package that will use .NET DLLs from a third party software package. Not all of our customers are going to use this package. If I add a reference to those DLLs in Visual Studio I can access the objects I need from them, but I assume that will break the build for other developers in my company who won't have this third party package installed.
What is the correct approach for me to be able to access this third party functionality without breaking things for customers and developers who won't use that package? Do I need to address this by creating my own DLL as a layer of indirection? Do I need to dynamically load the third party DLLs at runtime?
To my understanding, a .NET DLL is not loaded by the application until it is actually needed. This means if the DLL is referenced, but no code branch making use of it is reached, it is not required to be present. Perhaps it is not necessary to implement something in this case.
That being said, it is possible to use a technique termed 'hot loading', which means using reflection to explicitly access types contained in a .NET DLL. The technique is discussed in this question.
First, check if it has already been loaded; if not, check if the .DLL exists, and if so, dynamically load it with System.Reflection.Assembly.LoadFile. The reason you want to check if it has already been loaded is because the dynamic loader will often waste memory by loading additional instances.
It will be a bit more work, but by handling this dynamically, you can enable/disable functionality in your application that requires the assembly based on whether it is present, which will minimize unnecessary error reports from people trying to use it when it is not there.
Be careful in referencing the assembly when it is not there; although .NET will usually dynamically load only when an assembly is needed, newer versions are getting more aggressive in how they load, to prevent startup delays, so even if it works now (and that depends on the overall configuration), it may not work in the near future.
It looks like I will be using dynamic loading as described enter link description here. Props to Alberto for showing how to use the dynamic keyword with his answer.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
like this https://github.com/seesharper/LightInject/blob/master/LightInject/LightInject.cs
It's hard to reading, is there any deep meaning?
Being the author of LightInject, I feel I should comment on this :)
Say that you are a library developer and want to be able to utilize an IoC framework internally without taking a dependency on a third party assembly. By using the source version of LightInject, this can be done quite easily and you can still ship your library as a single assembly.
Many framework developers choose not to use an IoC framework just because they don't want that extra dependency.
The alternative to this would be to use tools like ILMerge that is capable of merging two or more assemblies into a single assembly.
This is a far more advanced option and would also require an extra build step that performs the merging.
Note that LightInject comes in two flavors, the source version where all the types are internal and the binary version that acts just like any other third party dependency.
Taking on a dependency might not seem so bad at first, but if you are a framework developer, you could easily run into issues if the consumer of your framework uses another version of the same dependency
Best regards
Bernhard Richter
It makes integration as source in another project easier: simply add one file to your project and forget about it. This is a supported installation scenario according to the official website of LightInject, there's even a NuGet package for it.
If you want to read it, I'd strongly suggest opening it in Visual Studio and using the code navigation features to find what you want, e.g. VS 2013's Solution Explorer can display the classes inside of a file as children of that file.