Is there a way in Fogbugz to track cross project cases?
For example, we have a business logic dll that is used in both the winform client as the web client. There was a bug there that needed solving in this dll.
Is there a way to make it so that adding a case to the project of the dll would autoamatically add this to the depending projects?
No there isn't a way to do this. You could either create two cases (one in each project) and link them, or in the upcoming FogBugz 7, you could make a subcase. But the only alternative to do this automatically would be to write something which scanned for these using the API and auto created the linked case.
I think you may get more focussed answers at the Fogbugz Support Forum.
Related
We have an idea to use ADX with MVC 5 and CRM 2013.
Is it possible?
We are doing background research on this whether to use ADX or not.
We have used ASP.NET with ADX previously.
This will help take a decision and will save our time.
Appreciate help if anyone know about this.
Adx portal - http://www.adxstudio.com/products/adxstudio-portals/
ADX offers a great product with an impressive feature list. http://www.adxstudio.com/products/adxstudio-portals/portals-features/
Like any add-on, look to see if there is something it contains that you deem as being vital and valuable enough to justify. Additionally, does your team have the ability/time to create the end product with or without ADX?
This is an opinion based question and in my opinion, none of the features alone justify the price. Especially seeing that ASP.NET + NuGet pretty much covers most of these features already.
Adxstudio Portals delivers managed forms by rendering a form in an Adxstudio Portal based on a particular form or view customization defined on an entity in CRM. Within CRM, entities can be customized and forms and views can be modified or created depending on your requirements.
https://community.adxstudio.com/products/adxstudio-portals/users-guide/managed-forms/
and
https://community.adxstudio.com/products/adxstudio-portals/developers-guide/web-controls/crmentityformview/
Above is the main reason us to consider ADX Studio.
ADX Studio, offers a good tool set to the client that has an internal developing team that will pick it up after you finish to customize it. Basically you provide some page template and the user is able to mess around with the forms to have a tailored experience (this works well when you don't have any logic on the page, just set the page and you are ready to go). Anything that is not in this category is custom made, means that you need to code it, and you will lose all the additional ADX benefits (for what concerns the read/write to CRM). Consider that a CRM developer is not a full asp/mvc developer, so anything that is more complex than change some code behind in a page template will create you problems, also all the jscript on the adx pages needs to be tailored, and you will need developers that are knowing the current web development standards, from Bootstrap to a decent js framework. Personally I'm not a huge fan, but the built-in authentication and some other features are making it a viable product. Consider that to customize it you will need someone that knows responsive design and js.
I am wondering what is the better way to go. I created a webapi project and am currently working on making my api.
In the future I want a full asp.net mvc 4 website and that could also contain forms to insert data into my database.
I am not sure if I should
a)
Make a new area in my web api project and build my website from there.
b)
Keep it in the same area and just make some new controllers and such in the web api project.
c) add a new asp.net mvc 4 project to my web api solution project.
Definitely two projects. In fact, I'd actually recommend three projects:
MVC website
Class library, for sharing your DAL/Service layers
Web API
Your MVC site shouldn't need to query your Web API, that's just going to create HTTP latency that's unnecessary. Both your MVC site and your Web API, are just "frontends" for your class library. They will both reference the class library and interact with the class library.
A Web API is only necessary if you're trying to provide third-party access or you're interfacing with a project in another language. If everything is .NET then just share the DLLs and call it a day.
K. Scott Allen recently wrote a brilliant post on the Coexistence of ASP.NET MVC and WebAPI it covers the most common scenarios and when it's appropriate to use WebAPI with MVC or when you should just use MVC.
I would use that as your guide pick the solution that best meets your current needs. My advice is to keep it simple and if your requirements are simple then there is no reason not keep WebAPI and MVC in the same project - it works just fine. As your requirements change you can always split them up into different projects or solutions, but by then you will know exactly why you are doing so.
http://odetocode.com/blogs/scott/archive/2013/07/01/on-the-coexistence-of-asp-net-mvc-and-webapi.aspx
absolutely,
go through link http://efmvc.codeplex.com/
which is the best architecture to develop the big apps
may this one is help you...
another BEST one MVC N-Tier architecture
MVC ---------> WEB API (services)------ > here BL | DL(ORM) | DB)
which you create this in same solution and build the app...
Separate projects for the web api and the web interface will help split things up, but it does cause duplications. We went that way recently and it works well, but it caused a few problems.
Arguments for having a single project :
Since we don't have a domain name yet, we have our API on the 8080 port. We could use a directory binding to make the API accessible from a sub-directory of the web interface but we were worried about production only bugs about absolute path resolution.
Many settings are shared between the two projects so we have to copy them in both web.config files.
Arguments for having multiple projects :
They are easier to upgrade since they can have different dependencies and they can be built totally independently. For example, our API project uses a few more recent versions of some dependencies.
It forces you to extract all of your business logic into a separate library and makes it easier to think about both projects as separate sub-systems.
It is easier to setup the web interface to a separate machine if the load is too much. This is a concern for us, but that may not be your case.
If I had to make this decision again, I probably wouldn't bother with separate projects unless the system was extremely complex and I needed the additional structure. An argument can be made for both options, but I think the deployment headache it brings is not worth it.
I'm investigating technologies to build a commercial SaS site for a shop that predominantly uses Microsoft technologies.
The idea is that the site will have pluggable modules, with features that are either free or paid. Customers will be able to chop & change between features, & have their billing adjusted automagically as they do so.
If I were rolling this myself, I'd use:
.NET 4 / VS2010 / C# / ReSharper / NUnit / Moq
NDependencyInjection
SQL Server
LINQ to SQL
ASP.NET MVC 3
Authorize.net (or possibly billing hand-off to SAP)
Selenium
... and hand-roll an IOC-based plugin architecture (e.g., there is some good discussion on ASP.NET MVC plugins here and here).
But at this point I'm wondering - has this been done before? I'm imagining some sort of vaguely CMS-like architecture with built-in plug-in, commerce & subscription stuff. All of that, rolled up into an 'off the shelf' solution, either FOSS or commercial.
Can anyone recommend such a solution, or is it simply a 'roll your own' job? I think DotNetNuke might be worth looking at, but would appreciate feedback from people who've used it in production for this sort of task.
Edited to add: DotNetNuke appears set on continuing with WebForms, which is a big turn-off for me at least. As one of the commenters on that post said, it's an evolutionary dead-end.
Edited again: Silverlight is definitely out for this project. We need to support a wide range of devices, including non-Microsoft mobile devices like Android and iOS tablets & phones. We do need a reasonably rich UI but we'll be doing that in Javascript.
For a project which needed plugable modules, I've used MEF (which comes built in to .net 4.0).
By using this great code for compiling views into a dll it was easy to use MEF to load additional views and controllers making extensability easy.
The only other thing i'd do differently to your suggestments is to use Linq to Entites rather than Linq to Sql. The latest code-first version makes it very quick to get things up and running
Martin
I've done a similar solution for a VOIP PBX solution. I've made everything myself using nhibernate, autofac and a couple of own libraries. It's not really different from doing a normal application.
The most important aspect you need to understand is that ALL modules are loaded at ALL time. Theres no way around that if you need a solution that works well (you could jungle with one app domain per customer but that's not very inefficient).
You should instead control authorization using the standard .NET CAS (Code Access Security) solution. You do this by creating your own IPrincipal and IIdentity. The principal should correspond the tenant (organization) while IPrincipal corresponds to the user.
I use a ITenantEntity interface (contains the tenant db id) on all of my classes/entities which should belong to a tenant. It's used to validate that the currently logged on user really have access to the entity requested.
The hardest thing is if your application is multithreading (for instance if you got a background thread or timer doing some maintenance). The reasons is that it's quite easy to forget to switch to the correct IPrincipal which makes all your CAS checks fuck up. The easiest way to go around that is to create a custom Timer and Thread classes which forces you to specify a IPrincipal (or at least makes it easy to switch).
Another common approach is to use the tenantId argument on all service / repository methods. But that isn't a very robust solution imho.
Why would anyone roll these in an 'off the shelf' solution?
These parts of the architecture are quite independent and you can substitute for whatever suits your needs.
I have an architectural question. We have many applications in our company and we are planning to use ASP.NET MVC and Entity Framework in our future projects. The next project that we need to implement is a central authorization/authentication system. There is no option to use an existing one for reasons that doesn't mater right now. This system probably will be structured as a service. What we don't know is: how the other applications will know about "the model" of this authorization/authentication system? I mean, how they will know user, roles, etc. classes? What is the best practice? One of our colleagues suggested to create the entity framework model (.edmx) in a class library. The problem is that in this case we should copy this dll for all projects that will access the authorization/authentication system. Is it a good solution? Does anybody has a better idea?
You can implement your service as a SOAP-based web service, which means your data model and methods will be exposed via SOAP and described using WSDL. The web service can be consumed from any language, without requiring you to distribute any class libraries.
Many languages also have tools which auto-generate client side class wrappers based on WSDL description of your SOAP interface (e.g. wsdl.exe for .NET clients).
Just to add to what DSO already said, the standard way to do this is through the "Add Sevice Reference" dialog box in Visual Studio. It will query your web service, figure out the classes that are needed, and put them in a reference.cs file. You can also use the svcutil.exe (or if you're using Silverlight, SLSvcUtil.exe) to do the same thing. You have to regenerate the reference.cs file every time you change the interface of your web service, but that usually only takes a few seconds.
It's also possible to create a distinct set of Data Transfer Objects that can be shared back-and-forth between the various layers of your application, but unless you have very strong architectural requirements, I've found the auto-generated classes to work reasonably well.
See also this article here about the self-tracking entities available in EF 4.0, if that's an option for you: http://msdn.microsoft.com/en-us/magazine/ee335715.aspx.
Introduction:
Now I know this question could be very broad and it would be too hard to answer without me asking something specific. So All I ask is just some direction, or a brief high level explanation of a design, or maybe there is already some framework out there that could help me get started...I'm not sure.. I have never designed a plugin architecture before, so maybe there is some resource/example you could point me to on the web that would help me learn so that I may come up with my own solution.
Details of my question:
My intention is I would like to create a plug-in architecture for a new pet-project that I am building in ASP.NET MVC.
I would like to design it so that it has some sort of plug-in ability for all, or at least most, of the application's components.
The reason I would like to do this, is so that I may be able to do deployments with nearly zero down time. The idea is that when I want to deploy the latest version I would drop in the new DLLs into a specific folder, and the application would load up the new plug ins and that is it.
For exapmle, lets say I add a new "contacts" feature to my web application where users can search, add and delete contacts. I would like to be able to deploy that by way of plugins.
Is something like this even possible for Web Applications? Or am I just dreaming?
It's definitely possible.
You will need to define a pretty comprehensive interface that represents everything your plugins will have to do. You should approach it by differentiating what is "core" to your application, and where the extensibility points are. For example, where will the plugins be accessed? Will they be tabs on a page, or links in a sidebar? What properties does each plugin need to have in order to fit into the plugin container?
Generally, plugins are enumerated via reflection by looking for assemblies that implement the plugin interface.
Just for encouragement, we've done this with an enterprise product that provides a generic framework for "management" interfaces for web sites. Developers just need to drop in a plugin dll that builds specific property pages, and they show up in the management interface menu, all the navigation is taken care of, and their dll's just have to worry about their own domain logic.
There is always the dll-way where you define some interfaces that plugins follow.
But for web application, especially ASP.NET MVC, you need a controller, views and so. Probably these can be included in a dll file using prepared controller factory to handle that, but it would be hard to develop these plugins.
Some inspiration for code (or db) embedded content: Haacked about that
ASP.NET MVC version 2 will support areas, where you can put some parts of the application into different folders within the app. This way you can just upload some files and the app will recognize these new files. Read more there Haacked blog
PS: I found another person here on S.O. asking the same question as me:
Plug-in architecture for ASP.NET MVC It might be useful for someone researching the same topic.