I have a question regarding c# open-source projects and dependencies. For example, I am currently working on a few projects. One is a C# project that produces a class library with specific functionality. This project should be hosted as other projects will find this functionality useful.
The next project I'm working on requires a reference to the class library project which is under separate version control.
So how can I structure an open-source c# project with a dependency to the class library project without including the source code of the class library project?
Any example projects to study would be great too! :) Thanks in advance!
If the open source depency is on listed on Nuget then the easiest way is to add the Nuget package, and make sure your packages folder and packages config file is included in the project.
Unless you want the actual source, then this is the easiest way to add binary dependencies. It includes the PDBs so you get the lines of the original source code.
Include a cmake script to gather dependencies in the application source code. The cmake script will check for dependencies, and any that are missing will be downloaded.
You could experiment with the cmake script being a pre-build step in the solution; But for now dependencies are updated manually.
The script is the same no matter which system it is on, which is the beauty of cmake's script mode.
Although this is a bit clunky, it seems about the best way to include a source-code version of an external dependency which is not a part of the applications version control.
as an example, you can get a launchpad project:
bzr branch lp:~brian-sidebotham/+junk/valverschatcam
from the root of this project, simply run:
cmake -P build.cmake
Obviously the script should probably be called deps.cmake or similar instead of build right now.
Related
I have created a system which loads dynamically a library and executes it's main class.
Everything works perfect, the problem I have is how to publish this DLL with all it's dependencies. As no executable project is referencing it I have to manually retrieve the dependencies: try to load the library, check the needed DLL's, go to the NuGet cache folder, copy the libraries, try again, check if it complains about more dependencies and so on until it has all the required libraries.
This is a true pain and I haven't found any information on how to do this, is it possible or am I stuck with this?
The library is a .net standard 2.0 library, I did this before with .net classic and the output folder always contained all the required libraries even the ones comming from a NuGet package, but with .net standard something has changed and now only libraries from referenced projects are being copied, no referenced NuGet package is being copied to the output folder.
Cheers.
Try:
dotnet publish
All the dependent libraries should be copied to the publish output folder.
At the time of writing, it looks like it's by design and there's quite some fuss and confusion about it, see logged issue on GitHub.
Moreover, when publishing a NuGet package for project A referencing project B,
B becomes a NuGet dependency in A; B's assemby is not included in A's NuGet package.
I deal with it by publishing my own NuGet packages.
I only don't like it to have a NuGet package for project B if that one is only relevant to be used with/by project A, as it will appear seperately in my NuGet feed.
TLDR: Convert your Class Library project into an Application, publish the application, and use application DLL as a library.
The long of it:
I tested this approach by deploying a full build with a plugin with many external dependencies to Ubuntu 18.04 and it ran perfectly.
Create a new project of type Console Application instead of Class Library. Put all your library code files into the Console Application and add the dependencies. Get rid of your original Class Library project (you don't need it anymore). Finally, publish the Console Application. You will get a DLL with all of the dependencies. You can use this DLL like any other DLL.
I suggest naming the console app project with "Library" on the end of it and adding a README just to document its not really an application even though the project is configured to build as one.
I have a project with some protobuf files. I want to compile these files to C# as a pre-build step.
So I add Grpc.Tools as a NuGet package to the project. And lo and behold, the tools are downloaded inside the solution's packages folder: packages/Grpc.Tools.1.6.1/windows_x86/protoc.exe.
Our CI server, on the other hand, uses a linux docker container (microsoft/dotnet). Is there a portable way to specify where to find the protoc compiler? Preferrably I would like to just ask the system: dotnet where Grpc.Tools or something.
I had a similar issue, in my case I wanted to pack C# code using ExcelDNA tools that come with the package. The post build event was added as part of the package install, but depended on the package folder been located in the solution folder, as you say. Porting the code to Net Standard we realised that the new version of nuget cannot deal with this specific issue of post build events which require the package tools to be in some folder relative to the solution or project. So to directly answer your question see here.
However you may not find that very useful if you want to do a post build event from the solution? If you are using jenkins et al and have a seperate step for packaging then the above should work fine.
There are a couple of ways around it. Most simply you can add the tools to source control, and then manually edit the post-build events. Depending on how you feel about that.
Secondly you can force nuget to resotre the packages locally and not in the system wide cache folder. You can do this through the Nuget.Config file. I have not got the specifics to hand, but if you cannot figure it out I can look in my old code.
I would like to know how I can share c# source codes between two (or more) .NET Core projects (commandline projects!).
As far as I understand, I can not link to source files in different directories in xproj/project.json based projects. I noticed that it now seems to be recommended to create nuget packages for everything. But is it really necessary for me to setup a private repository and create a nuget package only to be able to share some common source units?
VS2015 contains a template for .NET Core library which may be suitable for building a shared lib. Is it possible to link this lib to a project without a nuget package?
.NET Core Library is an excellent solution for you.
Do it the same way as in standard C# solution - just create the project and reference this project or add a reference to DLL file.
You don't need to use a Nuget, for your own purpose. Nuget packages could be useful to distribute your dll outside.
Clarification:
I miss one point - I'm using VS2015, but I have included Class Library project in my solution, and I'm referencing by project, not by DLL file, and this works fine in ASP.Net Core.
I also have a different project, where referencing DLL file directly working fine, but this is the previous version of ASP.NET app (not Core) - seems NET Core doesn't support this way like as the previous version (yet?).
Sorry for confusing you, sometimes it's too many technologies ;)
So could you just include ClassLibrary project into solution with your project and refer it as a project?
I have achieved this by using source control to branch from my commonly used projects in each new solution, and again merging back to the master branch if I make any changes.
Alternatively, baring in mind that NuGet is only an archived collection of files, you could keep this NuGet package locally, or even create a Template for Visual Studio that has the common libraries by default.
There are a wide range of possibilities that are down to your preference, and current environment state (I.E: Able to setup Source Control, or a package repository).
I need to make use of a UserControl defined in a Universal Windows class library from a UWP project which takes that class library as a dependency. (Both assemblies are mine.) In previous projects, when the project implementing the UserControl was part of the same solution, this worked fine. For my current project, I'm instead consuming the class library as a NuGet package. When trying to consume the UserControl from the NuGet package, everything builds but a XamlParseException is immediately thrown when loading the page which includes the UserControl at runtime.
I found this related question, which lead me here, which was enlightening (it seems a generated binary file for the user control isn't automatically included in NuGet packages for some reason), but the proposed solution doesn't fit my needs. The recommendation appears to be to move certain output files (*.xr.xml, *.pri, *.xbf) manually from one project's 'bin' to the other's, but this doesn't seem sustainable. If including these specific files in the NuGet package is the answer, then how can I do so automatically? Can I provide some specific set of parameters to 'nuget pack'? If I need to include a .nuspec file, what do I need to include in order to get the right files?
Some additional background on my project and workflow in case it's relevant: I'm building a cross-platform app using Xamarin and MvvmCross, currently targeting UWP and Android. The class library defining my user control is a Universal Windows class library which my UWP project depends on. I'm using Visual Studio Team Services to host repos for each of my assemblies; upon check-in, they are automatically built, tested, packaged, and published to an internal feed, where they may be acquired by projects which depend upon them. I'm looking for a solution which enables me to automate the inclusion of all required output files in my NuGet packages so that I can preserve this level of automation.
Short answer is no. There is no set of commands at this time that will make this work magically. You will have to manually specify the set of the files that is required.
An additional note is that you probably dont need to include the .xbf file in the NuGet package. The XAML Compiler will convert all the Xaml files (unless overriden) to .xbf, even those coming in from referenced Extension SDK's or NuGet Packages. However you do need to include the Xaml file since this will both enable the Xaml designer to work and is the input to the Xaml Compiler.
You could also look into writing a script that reads the csproj and updates the nuspec as required with the content that is needed as a pre packaging and post build step.
A good read around this topic is Tim Heuer's post here
I have used .Net Reactor to obfuscate code. Now how do I create create setup package for the obfuscated code. Or are there any other tool for creating setup package for obfuscated code.
Thanks in advance.
Not sure why this is a problem. Why don't you create the setup package before obfuscating the assemblies?
I had no problem with BitHelmet Obfuscator. My setup package just uses the obfuscated assemblies in BitHelmet's output folder, instead of project output.
Works fine.
Are you using the VS included setup project? For that, the obfuscator needs to support MSBuild based obfuscation, so that the obfuscation takes place as part of build process. This way, the obfuscated dlls are available for the setup project.
I found a way to do with Dotfuscator. Below are the steps.
You need to create Dotfuscator project first, i.e right click on solution->add project->select Dotfuscator as project type. To the project created right click on Input-> map to project output from your actual project. Build the Dotfuscator project. Next add the setup project. Point setup project output to that of Dotfuscator. And now build to create the setup. Now your code is obfuscated.
Now I am looking for a solution to work with .Net Reactor, obfuscation and add the output to setup package.
You can use the .NET Reactor VS Add-in in to automatically obfuscate the assemblies. This way your setup package will include the obfuscated files.
The solution is described here: Solution