I want to create a .Net class library and allow the users the option to either use the DLL or the C# source directly.
I know how to pack DLLs. I know how to pack source only packages (although it doesn't work for SDK style libraries). But I don't know how to allow the users to chose one.
This question has no answers and suggests that setting a default value for <IncludeAssets> is not possible. So by default both will be included and might cause conflict ?
This SO answer suggests to create two multiple NuGet packages like Foo and Foo.Sources. But I don't know how to do that in a neat workflow for a single solution/project either.
Any suggestions/resources or even example packages would be helpful.
Related
I have used the try-convert tool to convert my projects from .NET Framework to .NET 5.0
When inspecting the converted *.csproj files for projects that are targeting .net50-windows I noticed the element:
<ImportWindowsDesktopTargets>true</ImportWindowsDesktopTargets>
I am curious to understand what it does?
Is this essential or another example of something that try-convert puts in the *.csproj but is not really required to be present in the *.csproj any more?
Thanks.
The same happened when I used upgrade-assistant to do the upgrade and I also
wondered what the ImportWindowsDesktopTargets means and whether I needed it. I could find no official documentation for it, only this discussion. According to the question in the discussion, adding an ImportWindowsDesktopTargets property is one way to allow multitargetting using the TargetFramworks property, like this:
<TargetFrameworks>net472;net5.0-windows</TargetFrameworks>
<ImportWindowsDesktopTargets>true</ImportWindowsDesktopTargets>
As my project does not need to target multiple frameworks, just net5.0-windows, and as I have other projects, both Windows Forms and WPF, that target only net5.0-windows and work fine without ImportWindowsDesktopTargets, I removed ImportWindowsDesktopTargets from the converted project with no problems.
According to the proposed answer in the linked discussion, even if you do want to target multiple frameworks, there may be a better way to do it.
This is for pre-Net5.0 behavior to force importing WindowsDesktop Targets.
If you are using Net 5.0 or a newer version, Microsoft.NET.Sdk.WindowsDesktop will always be imported by the SDK, so you may remove it.
I have an issue including a self-built library to a C#-project. I have created an own class library called ClassLibrary1 just to learn how to add libraries on Visual Studio 2019.
So I have written some simple code in a newly created .NET-class library project and have clicked on "create new solution" (directly translated from my german IDE-language. Maybe it's called slightly different) after writing the code. Back in the C#-project, I have selected the dll-file from bin/Debug/ of the class library's project folder.
After I have set the checkmark, the dll-file was shown in the solution-explorer under Assemblys like expected. But the issue I now have is that I still cannot use the ClassLibrary1.dll-file in the cs-file in this very project as I expected via the command "using ClassLibrary1;". It only shows me the error message "type- or namespacename "ClassLibrary1" not found" when trying to compile the C#-project and I don't get, why this is the case.
It seems like it has to be a very obvious problem but after some research on the internet and trying some things by myself still nothing has changed.
Thanks in advance for helpful replies.
The by far easiest way to manage a library is to use project references. Ensure that your library and the project that uses the library is in the same solution. Then right click the "references" and select "add Reference", go to the project tab and add a checkbox for the library. Read more about managing references.
You might also need to add namespaces for the classes you wish to use in the source files.
I would not recommend managing using file-references to lose dll-files, since it can easily become a hassle to manage. I.e. if you create a new version of the library you would need to build, and explicitly replace this file in all other projects and update all the references.
If you want to share libraries between multiple solutions the more popular solution would be to setup a nuget server. This solves some of the updating problems by maintaining multiple versions of the same library, and provides a nice interface to update references in all projects. But this is a somewhat more complicated solution, so I would not recommend this for new developers.
This question already has an answer here:
Can you use a class library if you don't reference all of it's dependencies?
(1 answer)
Closed 5 years ago.
I'm trying to understand when it's necessary for my .NET project to reference a DLL that an external library references.
A practical example: Microsoft.Bot.Builder depends on Chronic.Signed.dll
If I reference Microsoft.Bot.Builder.dll, do I always have to also add a reference to Chronic.Signed.dll in my own project, even if I'm not using it directly? Or do I only have to only under certain circumstances?
If I reference Microsoft.Bot.Builder.dll, do I always have to also add
a reference to Chronic.Signed.dll in my own project, even if I'm not
using it directly? Or do I only have to only under certain
circumstances?
When you add packages using NuGet, dependent packages are also installed with them. So when you will add Microsoft.Bot.Builder.dll it will automatically install the Chronic.Signed.dll as well.
Now comes the part, Why? Some lib packages are dependent on other packages. Like a function in Microsoft.Bot.Builder.dll might be using some helper or main function from Chronic.Signed.dll. So if you will remove the reference of Chronic.Signed.dll you will will get error of missing dependency or reference.
do I always have to also add
a reference to Chronic.Signed.dll in my own project, even if I'm not
using it directly?
Yes, Because Microsoft.bot is using it internally.
Not all packages depends on others. Some are independent and never install any other dlls but some do.
You need to do this when you make use of something in Microsoft.Bot.Builder that exposes something from Chronic.Signed in its public API. For example (and without going through the libraries myself), let's say Chronic.Signed.IFoo is an interface that Microsoft.Bot.Builder.FooImpl implements. If you reference Microsoft.Bot.Builder.FooImpl in your code then you also need to reference Chronic.Signed so that your code has access to the interface.
Unless you're referencing specific things from those packages, you shouldn't need to. If you're missing a dependency which would cause your code to be unable to compile or run, the compiler will most likely complain about it.
Just as a simple example of when multiple DLLs need to be installed, when you're installing packages through NuGet, sometimes packages will have dependencies that will install in order to be able to run the code in the package. However, most of them will install independently of any other packages. You can test the how this works across projects by putting some references in a library project that don't exist in another project, and then trying to run the code from the main project. You shouldn't need to reference the same DLLs as the library project.
I need my C# desktop application to create TFS work items depending on my data.It should not use any further functionality: only connect to tfs and create workitems\tasks. I think solution of this problem should be simple and dont use a lot of code and a lot of referenced libs.
According to https://www.visualstudio.com/en-us/integrate/get-started/client-libraries/dotnet i should use these nuget packeges.
In https://msdn.microsoft.com/en-us/library/bb130322(v=vs.120).aspx article supposed to use Microsoft.TeamFoundation.Common and
Microsoft.TeamFoundation.Client libraries.
I'm a bit confused what to use, because in first case the memory overhead is too big(all libs = 60Mb when my app is only 10Mb) and a lot of redundand packages are used(some webapi, soap,sazure fetures).In second one i can't find them except as a parts of different packages.
I don't need help about write code, i need advice about least weight functional package to do this.
There is also the option to use the REST API instead of client libraries. This will remove the need to reference the Microsoft TFS libraries, but you might need other packages like Json or something.
For example, a call to https://{instance}/defaultcollection/{project}/_apis/wit/workitems/${workitemtypename}?api-version={version} will create a WorkItem (source)
That Nuget package includes lots of assemblies for all aspects of TFS (SourceControl, Builds, WorkItems, etc). You can add the Nuget package to your project but only reference the assemblies you actually need for Work Items and that should cut down the size of your compiled application package.
At work we have a tracing library that has to be referenced for all applications.
Recently following a major version change, the trace lib name changed as well
From
dotnet_tracing-w32r-1-2
To
dotnet_tracing-w32r-2-0
This broke several of our pre-packaged solutions (projects that have a main branch that get forked for customization to specific customers).
What I'm trying to figure out, is there any way to (auto-magically) reference one OR the other? Having the version in the filename is screwing everything up and I really dont want to maintain two separate branches of these projects.
To solve this problem, we used Conditional References
First I created 2 different build configurations - and based upon those build configurations, I used conditional references to reference the proper assembly. Finally we then use some post build scripting to generate our 2 different NuGet Packages and publish to our NuGet feed.