I have 2 Shared Items Projects (c++ if that matters) in my solution, sipA and sipB. They are included in a Console App project, C. I now want sipB to reference sipA so that I can make use of some of the classes there, but I can't seem to figure out how to do this. Is it possible, or do I need to give up on Shared Items Projects for this use case?
Related
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.
We have a VS2010 Solution which contains one windows form application and 4 Class Library (DLL) projects. (The class libraries are things like BusinessTier, DataTier, CommonCode, ControlLibrary) The whole thing is targeted for framework 2.0. Its been like this for three years.
Ok
So our application has grown to the point where we want to add a large new feature and marketing wants to deploy it as a separate product. Our product is used to fill in tax forms and the second product will fill in other tax forms.
We want to end up with two exe's (two install MSIs) which will be sold/installed/updated independently and could both be run at the same time on the same computer. Most of the code is in common between the two apps.
I am trying to figure out the best way to structure the solution to create the desired outcome.
1) Option one could be to create a new EXE project and several new DLL projects in the same original solution (Say in a solution folder) which have unique names,versions, guids, etc. with most of the code files as links back to the code files in the original similar DLLS. This allows us to have two completly separate systems with unique names for all the files, version numbers, etc., but allow any customization to be made to each project/dll. Is this a good idea or overkill?
2) Option two would be to create a new exe project in the solution and link to the same dlls as the first exe project. This seems simple enough, but i do not know if it is a good idea to have two projects which use the same DLLs. I do not really want to use the GAC. If we have two exe's which use the same Dll's ( even though they will be in separate application folders) with there be a problem if the DLLS have the same/different version numbers, name or GUID?
What are your ideas?
How should i restructure the solution to accommodate the new product?
Go for Option 2
There is no problem with the same Dlls with the same names. If you deploy the exes to separate folders or keep them in separate folders it will work either way.
I would even go further and look how you can break the application up further into more assemblies/dlls as it will give you even more flexibility. I would also have a single File for AssemblyInfo, and Add it as a linked file to all your projects. This means you have have a single version across all your dlls/exes.
http://vsh.infozerk.net/options/add-an-existing-file-to-a-project-without-copying-it/
Currently I have 4 solutions that are independent projects, however there is quite a bit of duplicated code when it comes to a few areas of the applications.
At the moment it is simply a few forms and their associated code.
When I want to change or improve something, I have to copy and paste to all relevant projects.
I looked at creating a new project within one of the solutions for the .dll/class library, but I felt that this was incorrect. (Please say if I am wrong).
As it is a component for all the applications, I decided to create a new solution for the .dll/class library and am looking at moving the shared code over to that - but, having never gone down this route before, what are my options from here?
Am I able to then include this solution within the others if I need to make a simple change and have it updated in all the projects or instead, should I always be working on the shared component in a separate instance of Visual Studio, outside of the applications using it?
That's exactly the right way to handle this situation.
You can include projects in multiple solutions by right-clicking the solution and selecting Add Existing Project...
Any changes you then make will appear in all solutions. The only problem this leads to is that it's possible to break one solution from another. This is where automated builds on commit to source control come into their own.
Put shared codes in separate Solution/Project as Class Library,
In post build event of shared projects copy dll's to a specific directory,
Add shared dll's from this directory to other projects/solutions
By doing this each time you build your consumer projects, they will use latest dll's automatically.
Moving the common code into a separate shared assembly is an excellent option.
One thing to think about is to keep your common business logic or business object type code separate from UI related code like custom controls - if you need to then have two common assemblies. This is more work initially, but makes things way easier further down the track when you need to make UI changes or change the control suite you are using.
My team is creating some standard VS solution templates. We have a well-defined project structure, resources, etc. that we need to use every time we start a new project and this is the perfect solution. The basics work nicely.
However, as well as defining folder structure (etc.) it would be nice to be able to import a number of projects from VSS/TFS. We have a number of shared assemblies that will be used by all projects and it would be awesome to add a reference to these projects when creating a new project via our template. Can anyone tell me if this is possible and, if so, how it can be achieved?
I think there are 3 types of items you might want to templatize (is that a word?).
New Solution
New Project added to a solution
New item added to a project
I'm not sure whether its possible to add existing projects to the solution that is created when a project template is run. http://msdn.microsoft.com/en-us/library/ms185308.aspx shows how to create multiple project templates. You may have to either manually add them to the solution or create a script that modifies the .sln file to do that part.
Adding an assembly reference to either a project or item template is easily doable. The project template is pretty simple since you just need to modify your .vstemplate file for the project template(s). See http://msdn.microsoft.com/en-us/library/ms171405.aspx for reference.
Adding a new assembly reference when you add a new item from a template is a bit harder but can also be done. See http://msdn.microsoft.com/en-us/library/ms185290.aspx for more.
Have fun!
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!