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.
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'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 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 4 years ago.
Improve this question
I have little C# experience. I have at one time maintained C# code on existing project. Now I'm assigned a task of developing a C# client connecting a server installed on local host. The server provides support for user to develop client in several languages. For C++, several folders containing dlls and headers, that's enough(I know how to use). For C#, several folders of .cs files. This way I don't know how to use. They're not compiled assemblies. May I need to include all the folders and cs files one by one into my own project and build them together? Please refer to pictures below:
C++ developer support:
C# developer support, I don't know how should I start to build a client:
The content under Support folder provides users ways to call interfaces which in turn connecting to the running server.
I'll generate a C# program using those files under Support\csharp\ folder.
I begin in this way as picture below, not sure if it's the correct beginning?
And about the error hint: if the namespace and the class name are same, how to instantiate it with new:
If there's no .csproj file, you must include them (cs files) in a C# VisualStudio project (.csproj), and compile/build them. You must know (and add) the external libraries used or deduce them from the using sentences (import's).
Then you can build that project in a external solution, and get dll to your own project, or add a new project on same solution and build them together.
It's a bad idea (namespace and class with the same name). Look at this SO thread: Namespace and class with the same name?. If you can't change it, you must set the path explicitly everywhere:
QQQClient.QQQClient quts = new QQQClient.QQQClient();
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 6 years ago.
Improve this question
Please i want Install Unit Test
'Xunit.Microsoft.VisualStudio.TestTools.UnitTesting 1.0.0-beta-1011'. You are attempting to install this package in a project that has '. NETFramework, Version = v4. 5 1' as a destination, but the package does not contain assembly references or content files that are compatible with that framework. For more information, please contact the author of the package. 0
The dll you are trying to add, Xunit.Microsoft.VisualStudio.TestTools.UnitTesting, doesn't match the target framework of your project.
Specifically, the DLL you are trying to add is a beta version needing .NET framework 4.6, and you project is currently .NET 4.5.1.
You could either change the target framework of your project, or look for a matching dll.
To see/change, target framework of your project:
Right click project's name
Click on "Properties"
There you will see "Target framework" dropdown (under Application tab, that should be open by default)
See: https://xunit.github.io/docs/getting-started-desktop.html#add-xunit-ref
As a side note, if you are experiencing the following error, after changing your target framework to 4.6:
Install-Package : 'NETStandard.Library' already has a dependency defined..., try updating your nuget installation.
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?