I have three applications in Biztalk (with three different DLL 's) which are all working fine.
For Ex:Solution A ,Solution B,Solution C.
I have to merge these three into single application ,generate a single DLL and deploy it.
Solution required:
Solution D with all functionality.
what can be possible methods to accomplish this ,if i don't have to build new project from scratch.
You need to create a new solution and copy all the artifacts from solution a, b, and c to this one. As a best practice, you should not have all artifacts such as schemas, orchestrations, maps in one dll/project. They all should be in separate assemblies but can be in one solution.
My official Answer, don't bother. There is absolutely no reason to do this.
There are no benefits...and no real drawback either.
If someone it telling you to do this, find out why they think this and we can help you explain to them how this actually works.
Create a new BizTalk project in a separate solution. Then copy all the artifacts from the other three solutions into this new project. Compile, deploy and configure in a new BizTalk application.
However, in general, designing the structure of a solution is a task that requires deliberation and effort considering the requirements of your application.
There are various best practices,patterns and guidelines , for instance here and here , that will guide anyone in the right direction.
Related
I'm creating a new MVC web application. I've never used MVC before (in asp.net). Anyway, in my last project, I used Code First and Entity Framework to handle my data and I enjoyed using that so I wanted to use it again.
Now, in the last project, I had a separate project/folder for handling the models and contexts, and I just referenced it into my main project. Would doing something like that still be the right choice in an MVC project, or should I just run it from the 'Models' section?
This is the website where I was learning how to implement this:
http://www.codeproject.com/Articles/468777/Code-First-with-Entity-Framework-5-using-MVC4-and
Is there anything wrong with that approach or is it fine?
Nothing wrong.
If your project is not big enough go for it. Having just one project make it simpler though that you must keep the code organized
If your project might get large, then it would be a good choice to have two project or more for different layers and tiers of your application, such that different guys work on their own project.
My team is doing web development (ASP.NET, WCF), and we are at a beginning stage where everyone needs to make DB changes and use own sample data.
We use a dedicated DB server, and we want each developer to develop against separate DB.
What we appear to need is ability to configure connection string on per-developer basis in source controlled way. Obviously, we might have other configuration settings that need custom setting and finally, we'll need to maintain a set of configuration settings that are common to all developers.
Can anyone suggest a best practice here?
PS Similar issue appears when we want to deploy a built application to different environments (test, stage, production) without having to manually tweak configurations (except perhaps configuring the environment name).
You can use config transforms for your deployment to different environments. That's easy enough. Scott Hanselman did a pretty awesome video on it here.
For your individual developer db problem, there isn't any particularly elegant solution I can think of. Letting each developer have a unique configuration isn't really a "best practice" to begin with. Once everyone starts integrating their code, you could have a very ugly situation on your hands if everyone wrote their code against a unique db and configuration set. It almost guarantees that code won't perform the same way for two developers.
Here is what I would recommend, and have done in the past.
Create a basic framework for your database, on one database on your test db server.
Create a Database Project as part of your solution.
Use .Net's built in Schema Compare to write your existing database to the database project.
When someone needs to change the database, first, they should get latest on the Database project, then make their changes, and then repeat step 4 to add their changes to the project.
Using this method, it is also very easy for developers to deploy a local instance of the database that matches the "main" database, make changes, and write those changes back to the project.
OK.
Maybe not so elegant solution, but we've chosen to read connection string from a different place when the project is built using Debug configuration.
We are using registry, and it has to be maintained manually.
It requires some extra coding, but the code to read the registry is only compiled in debug (#if debug), so there is no performance hit in production.
Hope this helps as well.
Cheers
v.
Right now I have a single ASP.NET solution with one project in it. The problem I'm facing is that multiple developers are working on different parts of the project that are getting released at different times. Because of this my project manager is thinking we can split the project into multiple dlls instead of just one dll so that we can update just the modules that need to updated.
1. Is splitting the project into multiple projects (multiple dlls) the correct way to solve this problem?
2. If so, how do I do this?
Can I just copy the appropriate aspx/cs files to the new project, remove them from the old one and build? What about Master Pages, CSS, Javascript and User-Controls, will I need to copy those along as well or can they be referenced in the "Core" Project? Would I need to make some adjustments in IIS or can I just copy the aspx from the new "sub-project" to the root of the "Core" Project (essentially where the aspx files are now)?
3. If not, what is the better solution to fix my issue?
Thanks for your help
Edit (to add a bit more clarity):
Right now our structure is something like this (shortened and code-behind implied):
MasterPage.master
styles.css
SplashPage.aspx
Page.aspx
AnotherPage.aspx
a_MasterPage.master
a_Page.aspx
a_AnotherPage.aspx
b_Page.aspx
b_AnotherPage.aspx
b_AlsoAnotherPage.aspx
Can I take all the a_ pages and roll them into one project and all the b_ pages and roll them into another (which would separate the dlls).
If this doesn't make sense please ask and I'll try to explain it better
Yes
How? Don't think in terms of pages, but rather functionality. The best way to handle your issue is to move the business logic out of the ASP.NET experience layer project and put it in class libraries. You can then have different types of developers working on different types of code.
Now, if you truly have different "sites", meaning they serve different purposes, then you may have to move some pages to one and other pages to another. I can't answer whether that is a need or not.
Hopefully, this all makes sense. NOTE: If you code is contained in Page_Load() and event handlers, you are pretty much screwed until you can refactor the code into individual methods.
3.) What about some version control system, wouldn't that serve you better?
Splitting project like this isn't a good idea imo, it would make sense, if you would like to split logical/physical layers of that project (you could have different project for your data access, another for business logic etc.) But splitting to projects, where one contains "welcome.aspx" and second one "contact.aspx".. hmm I would rather use SVN / Git / TFS / Whatever ;)
Normally you split the project according to the function or feature eg. you could split off the data access layer into a different project.
I ussually try to keep my view together and separate the core features, so it would be easy to use the same dll's over different websites.
eg: I have a project with all the methods and a db for user management.
I could deploy this project on a server and reference it in all my websites.
This way users can use the same login over all my websites.
So once you have a core system, everyone can make his own project and just reference the projects needed.
Yes you just move your aspx/c# files to a different project and reference the new project in your existing project.
I do think that every project needs his own masterpage though (last time I checked that is).
I hope this answers you question.
Let's say I have a Visual Studio solution with a Web project, a BLL project, and a DAL project. I'm trying to follow the repository pattern keeping my SQL code in the DAL with an interface that is referenced by the BLL.
I have a handful of common solutions for things such as error handling, usage logging, and other things that can be considered utility functions (i.e. not in the business spec). I'm keeping these in a Common project.
Here are a few ideas I've had with regards to structuring the Common project...
Bundle SQL with logic in a given class
Create a layered solution within the Common project
Discard the Common project and put utility functions in with BLL/DAL
Is one of these ideas better/worse than the other? Does anyone have a better solution?
It's worth noting that these utility functions will be reused in a variety of other applications.
Instead of creating a Utilities project which will be used have you thought about creating something that can provide a service? You might want to look at Aspect Oriented Programming. Red flags went up when I saw you listing off your examples error handling, logging, etc. Those scream AOP.
But if you want to stick with your layout.
I think I would go with 2, assuming that means restructuring the utilities project to be more Cohesive.
I don't understand (please clarify and I will edit my post)
Bundle SQL with logic in a given class
As for:
Discard the Common project and put utility functions in with BLL/DAL
I would be against doing so. If this logic is truly going to be repeated there is no need to push it back into your projects. This will lead to duplicate code and increased maintenance.
Side Note:
Just as a lessons learned, the only way Utilities projects work, are if you are the only developer or it is well documented and well designed. Sometimes utilities are too programmer specific, or are written in a way that only benefits a particular coders style.
I have seen countless times people rework their infrastructure pulling out all kinds of utilities, only to see their utilities project never get used. Make sure the "utilities" you are creating are truly useful to other people.
Do you have one solution with the web application project, class libraries, database project and tests? Or, do you segment it into multiple solutions? Why?
I'm asking because we're trying to streamline this scenario for Visual Studio 2010 and I'd like to get input from the community on how you'd prefer to work.
I tend (but not always) to have one solution per job, but I import existings projects from other solutions, such as my WebControlLibrary where I keep common user controls and classes, etc.
My actual solution for the job I then tend to break down into the Web Application, Business Logic Layer, Data Access Layer and Entity Layer, i.e.:
Solution
...MyCompany.WebControlLibrary
...Project
...Project.BusinessLogic
...Project.DataAccess
...Project.Entities
...Project.Scripts
...Project.Testing
...Project.Deployment
If a project requires something such as a mobile device, I'll always put that in a new solution, but it may perhaps share some projects of the current solution, i.e.
MobileSolution
...MobileProject
...Project.Entities
...MobileProject.BusinessLogic
The more 'stuff' you have combined, the slower Visual Studios becomes at building. You can obviously stop certain projects building by default, but that's when you have to start creating your own build configurations. If you are going to be creating large applications, I'd suggest breaking down into multiple solutions. I find it much easier to flick between solutions that to keep changing build configurations.
Another option is that when you build your projects you can reference their DLLs. I prefer to import said projects into my solution as you never have to worry about referencing the creating build configuration i.e. selecting the DLL from the Debug or Release folder.
Stand alone libraries can be their own solutions. References for those libraries can be made into the project that you're working with. Related items like the web application, the test setups, and specific libraries such as data access or business rules can be setup as projects within one solution. It really all comes down to how much you want to break things out for resuability.
This depends a little on the job the project performs.
For ease of use it's simple to have a solution that just contains all the projects required. If it's a large solution this can hamper you later on when the IDE starts to get slow and build times rocket through the roof.
Let's say one of the projects is a library used by your company to take card payments and interface with 3d secure. You present you're own GUI page to take the details etc.
If you had numerous sites that all take card payments you would greatly benefit by having this project in a separate solution and referencing the compiled dll. Any changes you require you would need to open up the solution, make the change, build it, go to the solution you're working in and test it. Sounds like a pita and you find it's just simpler to have it all in one big solution. But then if you have this library in every solution and make a generic change to it you need to repeat that change through out.
So you just need to make a decision on wether you're developing a separate project in the same solution or something that might be used elsewhere. If you needed more functionality than the library provides you could implement a partial class in your project and extend the library in that way. Or perhaps a wrapper class will suffice. But then you know you're not affecting the other sites that use this library and you are keeping your solution smaller and more manageable with a smaller memory print during development.