I'm trying to create a Dart backend framework that developers can download as a dependancy and have the basic folder structure, Dart files and such generated for them in their own project. From what I understand, downloading a dependancy package only places files inside the package directory/ies (although, I may be wrong).
To get around this, I believe Dart can be used like a Bash script, and can place files in the project directory automatically through running the package's bin files in the terminal (illustrated in the Running a script in a dependency https://www.dartlang.org/tools/pub/cmd/pub-run.html).
Would this be the best way to achieve the desired result? Or is there an easier way to download a framework as a project template? (I'd also like to place similar scripts for generating controllers and such in the tools directory, and don't know if keeping this framework as a dependancy would be necessary after 'install').
Thank you for reading.
You can use pub global activate some_package to be able to use pub global run some_package:some_script or just some_script to allow to run a script contained in a Dart package without adding it to the dependencies.
I think this is the best way to distribute it.
Related
I am trying to compile several scripts in my project into an easier to move and manage DLL file, however several scripts call UnityEngine.UI, and I know that the DLL file used to exist in /Contents/UnityExtensions/Unity/GUISystem/Editor/UnityEditor.UI.dll however the only data I can find for it now are the uncompiled files inside the Package Manager, where is the compiled DLL stored now?
The simplest answer that I just found is to look in the project folder of one of your projects in Library\ScriptAssemblies
We are migrating over to using packages and NuGet for managing our dependencies on 3rd party components. This works well when referencing packages from within Visual Studio or building on the build server via msbuild.
However there are a number of files that we would like to access in our build scripts and installers. Previously these would be in source control with a well known path, now as the version of the package that we are consuming changes so the path to the package and hence the files is changing.
Is there a simple way I can get the path to a given package? The best solution I currently have is to search for all packages.config files and extract the package version from them.
Examples of the files that we need to access are
The NUnit console executable from the NUnit.Runners package for running unit tests.
License files from various packages that we redistribute with our installer.
Using the packages.config file is a pretty good solution. NuGet itself uses two approaches:
Reading the package information from the packages.config and using that to resolve to the packages path.
Enumerating all the directories in the packages directory.
You could use NuGet.Core to do either of the above if you do not want to write the code yourself. The classes that can be used are the DefaultPackagePathResolver, the PackageReferenceFile and LocalPackageRepository or SharedPackageRepository.
One problem with the second approach is that sometimes NuGet may occasionally leave behind NuGet packages that are not necessarily referenced by a project. In that case looking at the package directories may give you the incorrect information.
The only other approach I can think of might be to read the project files looking for the assembly references. Although that would not work for a solution level package such as NUnit.Runners.
I would like to use NuGet packages for building packages for core helper libraries which I would like to add as source files into other projects. I want to use source files instead of libraries for several reasons, the main one being that I need them in SharePoint Projects, which is on the one hand much easier to deploy than additional libraries, and on the other hand helps to reduce version conflicts.
I know that I can add the source files as content to NuGet Packages, which would install them with the package. But this won't work together with package restore, and I don't want to have these files checked into source control in all projects.
Is it somehow possible to make a NuGet package which doesn't copy the files to the project, but instead adds file links, which point back to the file in the package folder, to the project? I think this approach would solve my use case.
Thanks
pascal
It is possible to add linked files with the use of PowerShell scripts, for example with this NuGet script: http://www.nuget.org/packages/Baseclass.Contrib.Nuget.Linked/
I am in process of setting up a whole series of NuGet packages for our framework. Beside the simple binary-packages (.dll's for modules of the framework) there are also packages that deliver source-code into the projects that are using them done with the \content directory in the NuGet package.
To develop this source-code I have a test-/sandbox project. I develop/debug/fix the code in this peoject and if its final for the next release, I copy it over to the package's content-folder where I replace things like $rootnamespace$ etc. This needs to be done for each and every version of the package.
Another way is to keep only the final source with the $rootnamespace$ tags in it and maintain that directly. But then testing/debugging would be done by re-adding the package to a test-project and debug it there, go pack to the package content, modify it, re-build and re-add and test it again.
So I see two ways to maintain the content-sourccode (none of them is really good):
Keep source-code in \content as small as possible and deploy as much as possible as binaries.
Generate the \content using some transformation engine (eg. T4) from the sandbox/dev-project. What engine would be best to use for this?
In short: I didn't find a good workflow yet to maintain the "content" source-code of NuGet packages. How are you guys doing this? Any ideas for that workflow?
Check the http://github.com/maartenba/MvcSiteMapProvider build. It is customized quite a bit but basically does a find/replace on several namespaces and replaces them with replacement tokens right before packaging.
I have some NuGet package that contains both DLL file and web related files like JavaScript, Stylesheet and image files. I want to create package that only install web related file to web project only (including ASP.NET and ASP.NET MVC project). What is the easiest way to do that?
Thanks,
PS. I think it should be possible via Powershell script. But I think, it is quite complex for me.
You probably want to use the Nuget Package Explorer. It allows you to create a package without the command line and add only the required files to your package (plus some easy config).
If I understand you correctly, you sometimes want to install just the DLL, and sometimes the DLL plus the web stuff. In this case it's best to create a separate package for the DLL, then another package with the web stuff which specifies the DLL package as a dependency of the Web package. This way it will automatically add the DLL when you add the Web content.
Here's a tutorial on Nuget Package Explorer that will probably help you.
I have a solution which I am using in several projects which works pretty nicely.
Create a second .Assets project, which contains the Assets, and reference all the files as links in your project, and mark them as embedded resources.
YourProject.Assets - contains the css/html/js/cshtml files
YourProject - files included as links, marked as Embedded Resource
Then include my EmbeddedResourceVirtualPathProvider Nuget package, and it will serve you assets from the Embedded Resources in YourProject.dll.
If someones wants to override the resources, they can install the .Assets nuget package and they will be included in their project and served.