I have couple of the those pic I loaded.First my question about first pic.why those folders seems with dot presented.when I look ad those folsers,it says they are "solution folders".why we need this folder ,for example I am creating a class libabrary as a project.why should I decribe this project inside the "solution folders".
first pic.
second pic
my second question about this solution struture.which created by Layered Architecture Solution Guidance 2010 download from here http://visualstudiogallery.msdn.microsoft.com/c8c473b5-21a1-447a-8b24-33b43411ee7f
It's already had bll,dal,bo, folder,why we need a share folder.which classes should we put inside it and I also see a test folder.whats primary responsibilityies on this solution.and how it is used.
thank you all.
First Question: Those are solution folders, which are just a way of logically separating the different parts of the solution (layers, etc.). You can only have physical folders inside a project (the ones that aren't dotted-lined): Visual Studio Solutions Folder as real Folders
Second: A shared folder could be used for classes that don't neatly fit inside either the BLL or the DAL. I can't think of a reason off the top of my head for one, but I've seen examples where shared classes are created in RIA services for Silverlight.
Bonus: The tests folder is for holding your Unit Tests. Look up Unit Testing for ideas. It is very useful to write Unit Tests for your code to provide a first line of bug-fighting whenever you create (do my tests run successfully on my new code?) or modify (do my tests still run successfully on my existing code after this change I just made). NUnit is a popular open-source Unit Test framework, and MS provides its own Test Project Unit Test framework built into Visual Studio.
Related
As title suggests, I am creating open source project that is in .net core 2.0. here is the architecture of it.
Now, it's working fine with everything including code first, seeders, swagger UI, TDD etc.
But there are many places where I have to add/modify classes when I want to add new Table in Database (see SimpleCRUD.Model > Entities)
So, I think I can reduce that boilerplate code, but I am not sure what is best way to do it.
What I did so far?
I tried to create a windows app, which will check and generate code for new added entity.
What I am trying to achieve?
Is there anyway I can add some kind of code in my current project and that will check after each build? is it feasible? any other suggestion to make it working perfectly?
Reference
I have checked this working in few other frameworks like serenity, asp.net boilerplate etc.
T4 temples can help cut down the boiler plate...
https://dotnetthoughts.net/generate-your-database-entities-using-t4-templates/
You've asked for my help here
I agree with other posters that you might want to look into T4. It sounds like you also want to create an MSBuild task.
I outlined the steps to do this for a different question in post here
You can find my code generators under this folder, CodeGen.SessionProxies
The t4 example can be found here: AppSessionPartials.tt
The MSBuild task can be found here: GenerateSessionProxies.cs
I had it generating a nuget file through the CodeGen.SessionProxies.nuspec. You won't find it on nuget.com; I had a local nuget repository. It would be helpful to you to look at the corresponding install.ps1 to understand how to set the generator up as a msbuild task.
Disclaimer: All of the GitHub links are subject to break if I ever decide to clean up that repo.
Cheers
We are starting to develop a new asp.net mvc 5 application that should be multilingual.
I found a very nice tutorial how to get this working. The only thing I wonder about this tutorial is, that the author suggests to create a separate project inside the solution for the resources.
Now my question: Is this recommended?
I usually create a folder called Resources inside my MVC project. Although if you wish to reference your resources from other projects, you may wish to create them inside a separate project.
I then sub-folder based on my controller names and change the 'Custom Tool' property to 'PublicResXFileCodeGenerator'.
When I use the resource strings in my Views, it looks like:
<title>#Resources.Home.Index.PageTitle</title>
Personally, I prefer to use a folder rather than a project, as this forces me to not generate UI strings in my application layers and forces me to find better ways to solve problems where I might end up generating strings in my business logic that might end up in the UI.
We have resource files in projects where they are most relevant.
We have a component that handles the translation of resources on different levels
( also for Winforms and WPF...)
and we group resource files according to functional importance,
bussiness level messages in a project for the Bussiness layer,
a project for common translations used by our standard code.
A .NET ResourceManager can handle one resource file, so our manager keeps a list of ResourceManagers.
At runtime you just try them all ( or work with logical category names to speed up the lookup)...
I want to associate one QC project with another (e.g., manual testing and automation testing). I use QC 11.00
I would like to know what kind of association there can be between two QC projects (on the same domain), so I do not have to maintain two projects and then copy paste what I need e.g. common repositories etc.
I'm not sure that you can do this. A project in QC is supposed to be a self-contained entity, that is, there is no way (that I know of) that you can automatically move data between projects.
Sure, you can copy and paste data, as well as create a project with another one as base, but that is probably not what you want.
I would rather have manual testing and automation in the same project, which makes more sense I think. The point is that the project is supposed to identify the test object, rather than the test methodology - the latter can be done better in Test Plan where you specify a Test Type when you create your test.
This way, you will have all defects and test reports for your test object in the same project which will make it all the easier to track what is going on.
As a general rule; you would want to keep all project data for one project in that project; and, you want project data from that project to be unique and separate from all other projects.
That being said... if you really wanted to do this (and were able to convince a QC subject matter expert that it was a good idea?), then it should be a relatively simple matter to amend the workflow with additional code to interface with another project.
Is it possible to compare two versions of a compiled ASP.NET application (V2, Webforms). When I say compiled I mean all the code is in separate Webform and Codebehind DLLs in the "bin" folder ie the "Use fixed naming and single page assemblies" publish option in VS.
Currently I used "Beyond Compare" to compare "Source" and it does an excellent job of this especially as one can compare 2 folders and it will go away and compare all the child folders and files. Unfortunately I have not found a way to compare a "compiled"/"published" application with it.
Thoughts?
Many thanks.
You can compare binary files from Beyond Compare. Just do a folder compare and when you have your folders selected, select the files you want to compare and hit the Compare Contents button to display the dialog below:
When you hit start, it will compare each file and tell you if they are the same or not. File that have this icon between them are not the same as each other.
If you're trying to find a way to compare the DLLs, take a look at the Reflector Diff AddIn.
This article offers a few other options as well.
Having seen several different ways of setting up larger projects in flex, I'm wondering what your opinions are of how to organize projects that are going to require 2 or more different applications. For example a public and private site within the project.
The two main ways that I know of would be first, creating one flex project, and then adding different mxml application files. Both applications would be able to share code.
The other way (which I currently like, but have no way of justifying), would be to create a different flex project for each application, and any code that needs to be shared could be part of a shared flex library. I guess something about the separation of the applications I like more, especially since I'm either working on one or the other at a time.
What are your opinions, and do you have any reasons for doing it one way or the other?
I recommend the library approach. That said, you can still use multiple applications in one workspace (and I do), but it's handy to keep the "one project, one application" rule. My workspace might have 5 projects, each of which has an MXML application, and 4 library projects, which have none.
I have used common library approach, it gives more decoupled code. Common library can also be used by some other projects later. Two applications in one project are mix and poor organisation for me.
One project with per application. I agree with everyone else. I would add that common libs are a good way to go as well. If you are working for a client that is having you build 2 or 10 applications then you will for sure want to reuse features as you are likely going to do this to save time and also so that the applications share common themes and functionality.
I find that a good rule to follow is if you tend to use a feature more than two or three times then it is a good candidate to be placed in a common lib.
I usually structure my projects by features. and example would be something like ... take an MP3 player application.
I would have the following packages
com.yourdomain.applicationname.mp3controls
com.yourdomain.applicationname.albumlistings
each feature would contain commands, model, view packages to start.
then maybe you find that you really like the mp3controls feature and you can use it on some other apps like say a video player application. The mp3controls could then be put into a common lib and then maybe renamed to something like "mediacontrols" or something.