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.
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 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 3 years ago.
Improve this question
I am the author of a number of open source of Nuget packages and I want my Nuget packages to be convenient to use for everyone, but it seems to be unreasonably difficult to configure Visual Studio to produce multiple assemblies targeting different platforms and architectures from one set of source code.
One of the major difficulties is that Microsoft does not do this for it's own Nuget packages, and therefore my project has to reference different versions of Microsoft's packages for each framework I want to target. This in turn means that I need different projects for each platform and this is awkward for projects with a large number of source files.
I can't help feeling that I missed something because many people must be suffering the same issue and it's hard to imagine that after so many years of development of Visual Studio this is still so difficult.
Can anyone recommend a pattern of organizing solutions, projects, source files etc that makes it easy to write code once and have it compile to multiple DLLs that target .Net 4.0, .Net 4.5, .Net Standard 1.0 etc.
Below is the way to set multiple target frameworks which results into multiple output folders to be produced.
<TargetFrameworks>netstandard1.0;net45;net40</TargetFrameworks>
I don't think there is other way to handle mapping between output platforms and versions of dependencies other than below:
<ItemGroup Condition=" '$(TargetFramework)' == '<version>'">
<PackageReference Include="<dependency_name>" Version="<version>" />
</ItemGroup>
A detailed description of the migration process from an older project is available here
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
I'm new to nuget package publishing.
The project under progress is a dot net core app and it's an open source project.
I undertand the two options content and lib when it comes to specifying target for distribution files.
Because so far I've not been able to connect a dll to a .net core web app on mac and the research indicates that the option is to have source code available for installation/deployment.
Second there could be users on the desktop that can develop their projects using the assembly dll provided.
Question is,
can user select what to get? dll or the source files?
Do I've to create a separate assembly for each, netstandard, netcore, net and uap?
I want to have the assembly (preferable) or source code available for all above mentioned platforms. The binary itself has some functionality that doesn't call any platform specific code, let's assume it's a HelloWorld class embedded inside a DLL.
Images from https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/
You can make 2 separate NuGet packages:
One that contains the library. Name it "Foo".
One that contains the source code. Name it "Foo.Sources".
Then the user of the package can choose by selecting which package they want.
Another option is to multi-target your NuGet package to both desktop and netstandard/netcoreapp. You would compile your assembly twice, and then contain the separate assemblies in a single NuGet package. There are a few good articles on the web describing this. Here's one: http://blog.csmac.nz/dotnetcore-multi-targeting/. The new .csproj format in VS 2017 allows you to specify <TargetFrameworks>net45;netstandard1.6</TargetFrameworks. You can `dotnet pack Then desktop and .NET Core developers can consume the same package, and they get different assemblies, whichever is built specifically for their framework.
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.
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?