My ASP.Net Core MVC project consists of 3 website projects, plus associated unit test projects, all collected in a single solution. Each of the website projects relies on common stuff, such as JavaScript libraries (under wwwroot/js/...) and views (under views/...). Is there some feature that lets me package up these files (none of which, as far as I know, can live in a NetStandard library project) and "install" them in all of my website projects so I only need to maintain them in a single place?
A razor class library (RCL) almost does what I want to do, but I want to be able to reference my JavaScript library from views in all three website projects. I also want the bundler/minimizer to be able to find my common JavaScript and CSS files. As far as I can tell, RCL only allows the Razor Pages in the RCL to access the static content (things like my JavaScript and CSS files) in the RCL.
EDIT:
After more thought, I've come to the conclusion that what I'm asking for simply can't be done "out of the box". In order to work correctly, the debugger and the bundler/minimizer need to find js and css files in the project's directory tree. What I'm asking for is a way to have something like a "reference project" that contains these "shared" files. I'm thinking that it's time for the "science project" approach: I'll create a reference project that contains the shared files, and run some code (at build time? via MSBuild? via unit test code?) that updates the files in the project from the reference project if they don't match.
FWIW, here's what I wound up doing:
In my 3 website projects, I have common files in several places:
Views/Shared
wwwroot/js/MyJsLibrary
wwwroot/css/MyCssLibrary
I created a "reference" project that contains copies of the common files in these folders. Then I created a unit test that simply verifies that the files in the "reference" project exist and are identical to files in each of the 3 websites.
No automated magic to keep the folders in sync. If someone changes one of the common files then the unit tests will fail until someone copies the updated file to the website projects and to the "reference" project.
Related
I have created three different solutions for three different clients, but those solutions are for an app that have the same features, classes, methods, resolution, except for the images, XML resource files, and a web service reference, that are specific for each one.
I would like to have just one solution for all those apps, that I could open in VS2010 IDE for edition, without errors. So, when I need to build or publish an specific app, I just set the client which one I need to, and go ahead to building or publishing.
It is important to consider that XML file names will be the same, as classes and images names too. The difference will be the content, but the name will always be the same.
My intention is to reduce my effort to maintain many solutions, having just one solution to work with.
In my company, we will have more than those three clients soon, so I am worried about how to maintain that. The best way will be have just one solution and when I need to generate a new app for a new client, I have just to change/include a few things (like some resources and images) and compile to a new client folder.
Is it possible? If so how?
One option would be to have a master solution which had the following
A "Template" project that contained your actual application and all of the shared code
Projects for all of your clients
In the projects for your clients, you could have links to the files in your files that come from your shared project. Then, in each of those projects, you could add the files that are only specific to them.
With this kind of structure, whenever you made a change to your Template project, all of the client projects would be updated as well because they just have pointers back to the Template project.
A good reference for this kind of setup would be the Json.Net Code Base. There he has a solution and project for all of the different configurations, but they all share the same files.
In terms of ensuring that the xml files are named properly, you might just want to put some checks into your main application to ensure that it has all of the files needed or potentially add a check into your build process.
There are many ways you could look to tackle this.
My favorite would be to run some sort of pre-build step - probably outside of Visual Studio - which simply replaces the files with the correct ones before you do a build. This would be easy to automate and easy to scale.
If you are going to be building for many more than three customers, then I think you should look to switch from Visual Studio building to some other automated build system - e.g. MSBuild from the command line or from something like TeamCity or CruiseControl. You'll find it much easier to scale if your build is automated (and robust)
If you don't like the file idea, then there are plenty of other things you could try:
You could try doing a similar step to above, but could do it inside VS using a pre-Build step.
You could use Conditional nodes within the .csproj file to switch files via a project configuration
You could look to shift the client-specific resources into another assembly - and then use GetResourceStream (or similar) at runtime to extract the resources.
But none of these feel as nice to me!
I am building a web project in Visual Studio that uses dojo, but I am unsure of how to link in the 3rd party dojo files so they get copied to the output directory.
In the past for things like jQuery, I placed the jquery.js file in a separate folder, went to "Add Existing Item," added jquery.js as a link, and set Visual Studio to copy it to the output directory (if newer). This worked great.
For dojo, there are hundreds (if not thousands) of related external files. This is not practical to add to Visual Studio (though I did find a way to do it in bulk).
This makes me think that I am approaching this incorrectly. How can or should I include something like dojo in a C# project without having to reference each file? Should I use a post-build step to robocopy the files into the output directory?
My goal is to be able to build multiple projects which all use dojo, but I don't want to have multiple copies of dojo checked in, or have to reference each file in the project.
Use the "Add as link" feature of Visual Studio.
http://msdn.microsoft.com/en-us/library/vstudio/9f4t9t92(v=vs.100).aspx
. . .
I am also a Dojo user. You will want to learn to do Dojo builds, to reduce Dojo to just a few files, and host them on your server. In many cases, in lieu of that, with some tiny loss of efficiency for the first load (after that, caching takes care of things) using the one of the CDNs like google to access the Dojo files is also effective.
Depending on your particular circumstances, it may be better to put the files out on a server, and just reference them in your HTML templates. This is, for example, how we do all our internal Dojo applications in my organization--three developers use one set of Dojo files for all applications.
I'd like to include some folders of static files shared between many projects and solutions.
These files could be images, script libraries or css that are shared between many projects.
I do not want to copy each time the folder inside the project structure but reference it just as we can link files between projects in the same solution so if any file changes in the referenced folder all the projects that link to it will have an updated version.
I know I can put it in a shared dll and embed resouces in it but I'd like to be able to choose witch folder to include.
Is this possible with Vs2010 or Vs11?
Sure, its possible, and not even that hard. Put the files in a well-known location in your hard drive, then add them to each project as a link. See the second section in the following article:
http://msdn.microsoft.com/en-us/library/9f4t9t92.aspx
If you use source control, I would strongly encourage you to have at least one separate folder per solution file, and nest the folder under your solution root somewhere. TFS, in particular, gets antsy if your solution file includes locations that are outside the current workspace. (It will work but you may get strange warnings or errors, particularly if someone else tries to get the solution for the first time.)
Being new to VS, how may I think of these two concepts, what is the difference?
I find some missing information in the other answers (at least for people who come from other IDEs like, say, Eclipse) . To say that a solution is a container for projects is only part of the thing. The conceptual feature of a VS project (what determines its 'granularity') is that one project produces one output: typically an executable or a library (dll). So, if you are going to code three executables that uses related code, you'll create one solution and at least three projects - probably more.
A solution is a container for projects, and tracks dependencies between projects.
Just to come up with a metaphor..
A solution is like a house, a project like a room. Each room provides a piece of functionality whereas the house, a container of rooms, provides the means to link the rooms together and organize them appropriately.
Kind of corny but I made it up on the fly, so bear with me :)
It doesn't help that Visual Studio seems to make things more confusing. "New Project" actually creates a new SOLUTION containing a project. "Open Project" actually opens a solution containing one (or many) project. (The file menu says "Open Project/Solution" but it really is opening solutions. There is no "Close Project" only "Close Solution" which is accurate.
So, in VS you are always working within a solution. Many solutions contain only one project and newer developers are likely to think of them as the same thing. However you can add other projects into a solution.
In case anyone decides to scroll down this far... I thought the MS docs did a pretty good job at describing the differences. I've copy pasted (and rephrased) the relevant bits here:
When you create an app, application, website, Web App, script, plug-in, etc in Visual Studio, you start with a project. In a logical sense, a project contains of all the source code files, icons, images, data files and anything else that will be compiled into an executable program or web site, or else is needed in order to perform the compilation. A project also contains all the compiler settings and other configuration files that might be needed by various services or components that your program will communicate with.
You don't have to use solutions or projects if you don't want to. You can simply open the files in Visual Studio and start editing your code.
In a literal sense, a project is an XML file (.vbproj, .csproj, .vcxproj) that defines a virtual folder hierarchy along with paths to all the items it "contains" and all the build settings.
In Visual Studio, the project file is used by Solution Explorer to display the project contents and settings. When you compile your project, the MSBuild engine consumes the project file to create the executable. You can also customize projects to product other kinds of output.
A project is contained, in a logical sense and in the file system, within a solution, which may contain one or more projects, along with build information, Visual Studio window settings, and any miscellaneous files that aren't associated with any project. In a literal sense, the solution is a text file with its own unique format; it is generally not intended to be edited by hand.
A solution has an associated .suo file that stores settings, preferences and configuration information for each user that has worked on the project.
A Solution can have many Projects.
The Solution can also handle managing the dependencies between its different Projects...making sure that each Project gets Built in the appropriate order for the final Solution to work.
A project contains executable and library files that make up an application or component of an application.
A solution is a placeholder for logically related projects that make up an application. For example, you could have separate projects for your application's GUI, database access layer, and so on. The projects would be specific divisions for your program's functionality, and the solution would be the umbrella unifying all of them under one application.
A solution is a readable text file whose extension is .sln and having a structured content that describes the projects that it contains. A project is a readable XML formatted text file whose extension is .vcxproj and having a structured content according to its XML schema, and whose primary purpose is to contain the listing of source codes filenames and their dependencies or references to other project's source codes as well.
Solutions are containers for projects - you can also use them to organize items that are used across different related project (shared dll's and such).
Solutions are containers used by Visual Studio to organize one or more related projects. When you open a solution in Visual Studio, it will automatically load all the projects it contains.
When you create a new project in Visual Studio, it automatically creates a solution to house the project if there's not a solution already open.
You can set dependencies of projects on other projects in the solution. The dependent project is build after the project it is depending on is built.
For more details refer - https://learn.microsoft.com/en-us/visualstudio/ide/quickstart-projects-solutions
If you are from an Eclipse background you would probably go to build path of a project and add a dependency on other project or add an external jar. In VS you can do that in a single container called solution where all related projects are grouped together.
Eg. Let's say you are build and android and iOS app in xamrin, there would be some common code and resources that could go in a separate project and then your android and iOS projects can depend on this common code project. Also you could have projects to test these projects etc.
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!