So far I thought that using Nuget to add the AngularJS modules is the way to go. But nuget adds the packages to whatever directory it is configured to. For example it adds the angularjs.core package to my main Scripts folder. It adds the angular-ui-router module again to my Scripts folder. But the angular-ui-bootstrap module is added to Scripts\angular-ui. If I am to use Nuget and keep the packages up to date, etc. I need to stick with this, which is inconsistent. Not to speak that I want to have all my angularjs scripts in a Scripts/vendors folder.
Can I somehow work around this problem or just ditch Nuget for this?
Related
I'm having issues creating a nuget package for a repo I've recently taken over (with no helpful input from the previous owner). The problem I'm having, is the VS nuget package creation doesn't seem to have any clear way to include other projects into the package. The way the package was built previously, was there's a base nuget package (package), that also included several other dlls from package.iOS, package.Droid, etc... But I can't figure out how to built it that way. The only other solution I can think of (which if I'm reading the nuget documentation on Microsoft correctly, it's the more correct way) is to create a separate nuget package for each of the projects, instead of including them all in the base package.
Please advise.
I am fully comfortable with creating multiple more specific nuget packages, but the people using this library are used to only downloading the base one, and it having everything they need.
I've looked into the documentation, and as far as I was able to tell, I could include referenced projects, but the base project doesn't rely on any of the other ones.
Just for reference, the project structure is similar to:
project
project.forms
project.iOS
project.Droid
project.macOS
project.Uwp
Where previous versions of the nuget built from project also included project.iOS, project.Droid, project.macOS, and project.Uwp, which in turn, depend on project.
Logically, to me, it seems that each of the project.{}s should probably have their own package, as they all may not be needed in someone's utilization of the package. Just wanted to see if there was an easy way to continue existing patterns without a load of work.
Scratch that
Turns out I can't make individual packages out of the project.{} projects through VS.
Okay, found it, just had to make a .nuspec file, and reference that file in the nuget pack command.
In the .nuspec file, you need a <files> node with a <file src="...thing.dll" target="lib\..." /> for each of the dll's you're needing in your project. Simple as that. Just wish there were a way to do it in the VS interface, instead of having to use a .nuspec file.
I seem to be having the same problem as this unanswered question.
NOTE: Ordinarily, I'd avoid the repost, but the lack of an answer and the low traffic seemed to warrant a refresh into the SO feed.
The setup
Create two .Net Core projects (A & B) in two separate solutions in the same folder. From A, create a Nuget package. (You can upload it to Nuget, MyGet, or just keep locally. Just make sure the source is configured.)
In B, add the Nuget package.
The result
Project A has now been added to the solution for Project B.
The questions
Why is this happening?
How can I get VS to recognize that it should be referencing the Nuget package, not the project?
Other stuff
I'm running VS 2015 Pro Update 3 on Windows 10.
In my real scenario, my Nuget package is at a later version. When I open the project.json file, I get a compiler warning on the ProjectA dependency that says I'm depending on version 1.1, but version 1.0 is found.
I've created an example on GitHub for you to play around with.
You must place the solutions into separate directories as .NET Core Projects in VS2015 has unique file system requirements, and will behave poorly when you put them in the same directory (each solution will generate a hidden .vs folder, and they will end up overlapping).
For example you could change the directory structure to this:
.\Solutions\A\ <-- Directory for Solution A
.\Solutions\B\ <-- Directory for Solution B
.\A\ <-- Project A
.\B\ <-- Project B
This would mean that the hidden .vs folders for each solution will no longer overlap (ie, the solutions do not share this)
.\Solutions\A\ProjectA.sln
.\Solutions\A\global.json
.\Solutions\A\.vs\
.\Solutions\B\ProjectB.sln
.\Solutions\B\global.json
.\Solutions\B\.vs\
Local projects take precedence over NuGet packages. I don't know at what level this is baked-in, though.
The solution is to explicitly specify in your project.json that you want to reference a NuGet package and not the project in the same solution.
"YourNuGetPackageName": {
"target": "package",
"version": "VersionOfYourNuGetPackage"
}
You can have a look at an example here.
In large scale software, it's a good idea to break code into projects.
For example, have a framework project which contains all base classes in some project called Company.Framework and some other projects which uses those shared codes like Company.ProductA, Company.ProductB.
Is it possible to reference .ts files in other projects, for example just referencing its dll, not adding the project, so the framework project can be hidden from the business developers.
The question is how to reference .ts files in other projects without adding those projects to the solution. For example just by adding their dlls.
I'm sure you know this, but Typescript files (.TS) get compiled to Javascript files (.JS). Neither the Typescript files nor the generated Javascript files end up inside the DLL. The DLL contains server-side code only, and the Typescript/Javascript is client-side code.
So, trying to add a reference from your ProductA project to the DLL from the Framework project is not going to pull in any Typescript files that were in your Framework project.
As long as the final rendered HTML page includes the tags for both the generated Javascript from both ProjectA as well as Framework, then everything will work fine, even if the two projects have no connection between them. If what you're really after is Visual Studio Intellisense for the Framework classes while you're coding in Typescript in ProjectA, then you should do as #WedneyYuri and #DavidSherret suggested, which is to add the .d.ts file from your Framework project into your ProjectA project.
Managing Dependencies
The simplest solution is to use a package manager like bower:
On terminal: Create an empty folder and start an empty bower repository:
$ bower init
For each definition file use this command:
$ bower install [URL] --save-dev
Example for jQuery definition file:
$ bower install https://raw.githubusercontent.com/borisyankov/DefinitelyTyped/master/jquery/jquery.d.ts --save-dev
Thanks to the bower you can use any URL here. For more information visit the bower documentation.
Compilation
Create a file (name isn't important) definitions.d.ts in the same folder where you ran the command $ bower init.
For each installed definition file you must add manually a new line in this file:
example after adding jQuery and angularjs:
/// <reference path="jquery.d/index.ts" />
/// <reference path="angular.d/index.ts" />
Now, in your project you only need to include references to the definitions.d.ts file
Running the code
For the code to work you need the .js files. In development environment I use the bower to manage the dependencies in a separate folder and I manually add the .js files in html. In production use any tool to concatenate them.
TSD (TypeScript Definition manager for DefinitelyTyped)
In the near future the package manager will have option to install modules from anywhere. It's not ready, but it is a goal.
The goal of TSD future is to seamlessly support any TypeScript
definition files, from any source. By default, you should still be
able to search the definitely typed repository and install from there.
However, more focus will be trained onto support independent
definitions, specifically ones bundled with modules.
https://github.com/DefinitelyTyped/tsd/issues/150
I want a custom directory structure for my Content in my MVC project for example:
\Content
--\js
--\css
--\img
Is it possible to tell a NuGet package to install scripts in the Content\js folder? For example the jQuery package so that the jquery-1.6.js file is installed in the Content\js folder?
A workaround is to use the Nuget Package Explorer and download the package you want into that. You can then edit the folders within the package using Package Explorer to suit your taste and save it into your own Nuget repository. This can be a file system folder or you can get more sophisticated here: Hosting Your Own NuGet Feeds.
Of course this means that you have to keep the packages in your private repository up to date. Clearly if you have a lot of packages to deal with this could become a problem. However it seems quite likely that a future release of Nuget will deal with the issue of local feeds because it's an issue for companies that 'restrict which third-party libraries their developers may use' as mentioned in the Hosting your own NuGet feeds reference above.
I believe the answer to that is "No." There are, however, some references to be able to set the root folder NuGet installs things into: http://nuget.codeplex.com/workitem/215 (see the comments)
How jQuery gets installed is determined by the package producer, which is the jQuery team in your case.
Where the jQuery package gets installed is up to you.
However, the where can only be adjusted in terms of the location of the installed package ($(SolutionDir)\packages folder is the default), and the target project where you install it into. From then on, the package producer takes over and decides where each piece of the package content ends up.
There are some good conventions for ASP.NET MVC, such as a Content folder, a Scripts folder, an App_Start folder (for WebActivator), etc. Think about the risks and extra effort involved of trying to move away from these conventions. Do they outweigh the benefits?
Now if you really want to use your own conventions, you could create your own package with your desired content structure and put the jQuery scripts where you want them in the consuming projects.
This means you would be using your own package with that specific version of jQuery. You just have to be careful to respect the licensing policy of the original package, and not to break any specific installation steps or requirements from the original package, which is fairly easy to do if you manually start changing package structure.
The answer to this is "no" because the "Content" folder is one of the Nuget's convention folders. However, if you rename your Content folder to, for instance, public and then have Nuget pack your public/js folder then when you bring the package in it will extract the files to the public/js folder.
Since I started to use Nuget I switched to using public for my public content instead of Content and rather use Content for files that I want to bring in untouched like source files (see here one usage of Content).
I have been using the Codesmith framework NetTiers to generate a DAL etc., into a folder called, say, 'NetTiers', outside my main project's folder, and referencing the DLLs within that folder from my main project.
I've started using the Plinqo framework, and want to use the generated files from that framework within the same project as the one I'm using with NetTiers. (The reason I'm using both frameworks is that I want to get/learn the newer LINQ goodness from Plinqo, yet also have the familiar NetTiers code DAL, BLL syntax available, for compatibility.)
My question is: what's the best Visual Studio solution and file structure to use when using Codesmith templates like these? Should the frameworks' generated code be contained outside the main project and added as projects to the overall solution? Or should each template's generated code have its own solution? Should the generated files be within the main project's file structure?
I've tried combinations of each of these, and they each have their pros and cons. I'd like to know if there's a tried and tested pattern.
When it comes to .netTiers, I always compile the generated solution and add the assemblies as references to my project. This makes it much easier to upgrade/diff and regen.
However, there are going to be some cases where you would want to add your custom logic so keep this in mind.
Thanks
-Blake Niemyjski
I tend to just keep the .csp and the generated folder outside of my main app's folder. When adding a reference Visual Studio copies in the .DLLs from the built generated code. All of the generated projects sit under a main folder such as D:\CodeSmith Projects\
If you want to version control the .csp file it might be beneficial to move it in with the rest of your version controlled app files to tie it all together.
We put the generated projects inside our solution. In fact on my current project I generated the nettiers files to the location that I wanted the files to be, and Started adding my own project files to that...But we have always kept the files in the solution, that way if i need to add something to the code in the concrete classes I can do it without having to open a whole new project.
We have tried both scenarios. We settled for including the assemblies in a dependencies folder, which was shared by multiple projects.
We had problems with TFS when the projects were included in the solution. the downside, is that you can't so easily step into the .NetTiers generated code when debugging, though after a while you get used to this, and accept that whatever is in .NetTiers stays within .NetTiers!