I have a new HTML helper, SelectionOtherTextBoxFor. It is a textbox linked to a <select> element1 for capturing the actual other value if the user selects 'Other' in the select list.
It has some JavaScript, HtmlHelper code, and some attribute code.
How do I package this so that other developers can just install and use it, without a list of files and where to put them? I suspect Nuget, but maybe there is a simpler way.
Otherwise, please may I turn this into how do I go about doing this in NuGet?
The easiest would probably be to package the code in a class library that other developers could reference in their projects. As far as the javascript part is concerned, you could ship it alongside the class library.
If you want to automate the process, NuGet is definitely the way to go. You should read the Creating and Publishing a NuGet package guide which contains very detailed instructions on how you could create a NuGet package and include dependencies in it. In this case you will have the assembly containing the custom helper and attribute and javascript file as a content to the package. The javascript file could then by default be deployed in ~/Scripts when some developer installs the NuGet.
Personally I have always used NuGet for those kind of things as it offers lots of flexibilities.
Related
I am writing a R package for my Msc's project, together with some .Rmd analysis that uses my package and generates some html reports.
I consider both the package code AND the resulting analysis as deliverables for my project, so I would like to showcase the two in a same location, maybe the same github which is already hosting my package. Question is, can I just add a /reports directory to the package structure and put my html files inside ? As package will be mostly internal use, I don't plan on submitting it to CRAN anytime soon if that matters. However, I would also like to avoid distributing my reports to other potential users.
I've just found out about the .Rbuildignore file which seems like it would do the trick, but I'd be curious to hear what's the standard practice in this case or any other suggestions you may have.
Thanks,
I'm getting started with FunScript with a working example. Using Nuget to add the needed libraries, it works well.
In watching a 2013 video on channel9, they are making use of TypeScript.Api<...> to load types from typescript definition files.
I'm however unable to find this type provider anywhere.
Where is it located?
I realized that a good number of the type definitions have been compiled into libraries and available on nuget but I can't really use this since some of the code will be local typescript definition files.
The questions therefore are
Where is the TypeScript.Api<...> type provider?
If it is not available or the best way to use typescript definition, what other options exists.
As Thomas said, the type provider was removed mainly because it couldn't generate generic types, but the idea is to bring it back at some point.
For the moment, though not ideal, you can generate your own bindings following these steps.
Download or clone Funscript repository
git clone https://github.com/ZachBray/FunScript
Build the project
cd FunScript
build.cmd
This needs to be improved but for now you need to zip the .d.ts files you want to convert and then:
cd build\TypeScript
bin\FunScript.TypeScript.exe C:\Path\to\typedefinitions.zip
cd Output
Please note the first time you build the definitions it may take several minutes. Once it's done in the output folder you'll find the compiled .dll libraries with the bindings.
Also, while you're at it. It's better if you use the FunScript version you just build into build\main\bin, as it will probably be more updated than the nuget package.
Good luck and have fun(script)!
There were a bunch of changes in FunScript, so the TypeScript.Api<...> type provider is no longer the recommended way of calling JavaScript libraries from FunScript.
Instead, the bindings for JavaScript libraries are pre-generated and you can find them as packages on NuGet, if you search for the FunScript tag (NuGet search is not very good, so you may need to go through a number of pages to find the one you need...).
If you want to use a local TypeScript definition, then you'll need to run the command line tool to generate the bindings. The F# Atom plugin does this in the build script, so looking there is a good place to start. It has a local copy of various TypeScript bindings in the typings folder (together with the FunScript binaries needed to process them).
I liked the type provider approach much better, but sadly, type providers are somewhat restricted in what kind of types they can provide, so it wasn't all that powerful...
VS2013, MVC5, VB
I am nearing the completion of a small project to manage the roles tables in a standard MVC5 application. The code is pretty much encapsulated. What are my options for using this 'package' in other projects?
Can I compile it into something? I know this type of action is possible, I'm just not familiar with the options available to me or the steps to do this. Links to sites that have tutorials are fine. Is creating a Nu Get package the only way to go, or is that even in the ballpark of what I'm asking. I say Nu Get, but I don't mean for public consumption, only for my consumption.
Will the finished 'whatever' include it's controller class, view models and views? Will I be able to easily manage updates? etc.
Creating a Nuget package is one way. I have created a local repository of common utilities for this purpose. But I usually use it just for DLLs. I use Nuget Package Explorer for its ease of use since its just me using the packages most of the time. Not sure its possible to place the files in specific directories.
Files in the content folder are copied to the root of your application when the package is installed. - Nuget
The alternative is to create an item template. I used to use this method for class files I want in my code but I can't see why you couldn't do it for the rest. Works well and isn't too hard to set up. There are dozens if not 100s of tutorials on the subject. Here is one on code project.
I have two environments that use Umbraco: Live and Dev.
As I have in research, Umbraco will be create a physical file when a user creates a new partial view, macro, etc. so, I have two questions:
1. What is the best way to know which files were created on Live and how to migrate them to Dev environment for the purpose of creating new features?
I have tried to Google and found "Hybrid Framework" but it is not up to date and I want to maintain code by myself.
2. I want to extend Umbraco with my own code. What is the best practice for this? (I do not want to change any code in the original Umbraco Source, just create my own new code)
As I know, I can create a package for extending code but I just want to know the other ways.
Partial Views, Macros , Templates are .cshtml files, these will not affect your source code. Same is case with css and js files; these will not harm any source code.
Just copy paste these files in respective folders and reload the nodes in backend. It will work properly.
Other way is you can create a package zip file from developer section where you can export datatypes, content and files, and install it in other environment.
I'm hoping someone can shed some light as to why this is happening. I've just started creating my own packages in Umbraco and am having issues with something that should be quite straight forward.
I've created a fairly simple package consisting of a Content page and child pages, doc types, templates, some css and some scripts. I install the package on another Umbraco site and all seems fine. The problem is when I come to uninstall the package, it is trying to remove its parents Document Types, which it cannot do, and it's shouldn't do as these were not in the original package I created.
What am I missing here people?
Thanks in advance!
The package manager will attempt to package up all required dependencies.
When you created your package did you select doctypes that were nested under the parent doctype? If so this is probably why as the parent doctype then becomes a dependency and most likely was actually included in your package. It should be pretty easy to see from the uninstallation page what it is trying to remove and if that doctype is listed it was in your package.