I'm working on a sub-application for a large system.
There is a company X which has created the system. Sub-applications are created by numerous smaller companies, including the one I work for.
Our application is close to being finished but there is a new requirement that our application must not use DLL files and all the business logic should be contained in .cs files.
Why is there such a requirement? Company X believes it can solve the problem of having too many DLLs and dependency issues. With many sub-applications and many different companies creating them, problems arose with /bin directory and dependency issues.
Main problem is that many sub-applications are interlinked. Service Oriented Architecture is used.
I understand this is an architecture problem. And requirement also came way too late.
I'm a developer.
More specifically about my problem:
It's simple when it comes to ascx.cs files, I can just switch from CodeBehind to CodeFile. No problem here.
Problem is with our libraries. Obviously, I can just copy all the corresponding .cs files on the server but how do I make the application load the classes from there instead of using DLL libraries?
I have never implemented an asp.net website without using DLLs, it is not clear to me what are my options.
I have been reading about:
How to load a class from a .cs file
I hope I've explained my situation well enough.
Company X no doubt has someone leading the developers who once had a dependency issue. They have now decided that any and all dependencies that are in the form of an actual assembly are bad (I think we've all had a manager like this at some point).
The fact is: this isn't possible. It is a stupid requirement that makes your life much, much more difficult.
You have two options that I can see.
1) Remove all of your (hopefully) nicely decoupled assemblies with their nice business logic out into your code behind files. This is tragic.. but an option.
2) Continue down your path of investigating compiling code from a source file. This sets you up for a HUGE amount of extra development time and.. honestly, you'll probably just end up giving up.
Save yourself some hassle and just offer them your full source code on USB.
Sorry if that sounds harsh. I do not envy you though.
Offer to license your source code to them but at much higher price than the binaries. Source code has much more intrinsic value, because it is your intellectual property.
Also beware that company X can decompile your binaries into source code using e.g., ILSpy. How much do you trust them not to do this?
Related
I am new to SpecFlow and I am wanting to reuse steps/tests (.feature files essentially) between solutions. I know there is a way to reuse steps between projects in the same solution by adding a reference to the project but I'm not sure exactly how to do essentially the same thing to a different solution. Thanks for any help on this one.
You cant reuse .feature files but you can reuse step definitions and hooks.
You will have to add reference to the project.
Here is the link how to reference a project in Visual studio: Link
I do not think it is possible to use steps from a different solution. You will need to include them in your working solution somewhere to use them. I don't think Visual Studio has the option to let you use inter-solution code unless you have compiled it and reference it within your working solution.
Doing this is a bit of an anti pattern. The reason for having feature files is to talk about WHAT the application does and WHY its important. So feature files should contain things that are unique to your application domain, and there won't be much overlap between projects
When you write features this way even common functionality isn't really worth sharing, because the complexity outweighs the simplicity of doing things again.
For example logging in is ripe for sharing between applications but all you need in a feature is
Given I am registered
When I login
Then I should be logged in
This is so simple that its easier to just write another one for your second application.
Most steps that people have shared other the years are all about HOW things are done e.g. clicking on things, filling in fields etc.. These generally lead to bloated scenarios and again the cost outweighs the benefits.
If you still feel there is alot of shared behaviour between your applications you may have an architectural problem where you need to extract the shared behaviour into its own application, and have your applications delegate responsibility.
I am looking for the best solution to make it easy to add new languages to an asp.net website without deploying/building the existing code base.
From what I have researched, it seems that you can compile resource files on the fly into Satellite assemblies but I am uncertain how to make the application use these DLL's once generated?
The other option I have seen is to store the translations in the Database, and write a custom ResourceProvider so that the built-in localization methods can be used, whilst abstracting the actual implementation (in this case a database).
Either way, the front end for this site will be the same (meta:resourcekey for the controls etc).
But I am struggling on deciding which approach will be the easiest to upkeep. For example, does publishing a new Satellite Assembly restart the Application Pool or does everything tick over nicely?
EDIT
The translations will be provided by a 3rd party API so human maintenance quality is not important. I thought I would add this due to the answers received.
With Asp.Net (currently) you do not have to compile by your own, you can simply deploy resx files (to App_LocalResources or App_GlobalResources folder) and Asp.Net will take care of compiling them into Satellite Assemblies. That's cool.
With Database approach, you are risking the problems with synchronization: how will you know if given resource string is translated? Also, correcting them is not very easy (for Translators/Localization Engineers). And you would need to prepare "install" script anyway. If that is what you are going to give to translators, good luck. You would face plenty of overtranslations and you would have to correct them (manually?).
Resx files (being simple XML) are a bit easier to validate (it is either valid XML in terms of given XSD or it is not). Besides, it is standard technology, you won't need to implement anything by yourself. That is why, I would recommend it.
EDIT
Another issue with Database-driven resources could be character encoding. You would need to create your own translation kit. My experience is, the result might be in several different encodings. Especially, if you want to use plain text file. On the other hand, default encoding of XML files is UTF-8...
RESX
Having around 30+ languages in mit Windows Forms and Web Forms application (this one, if I'm allowed to place a link), I finally had most success with simple RESX files in App_LocalResources.
What I discovered though was that the compilation was extremly slow in VS.NET, so did a slightly modified approach:
Have only English RESX files in the VS.NET solution.
Have a shadow structure of the website with only the App_LocalResources for all languages, including English in a separate folder, not visible to VS.NET.
Write a simple CMD script to copy the real English resources to the separate folder.
Use my free tool Zeta Resource Editor to actually translate inside the separate folder.
Have a publish script that copies the real web files (like ASPX, ASAX, MASTER, etc.) to the website and also copy the resources to the websites.
This approach makes compilation really fast and still allows me to keep compilation and translations separated.
The drawback is that the first call of the live web application compiles rather long, until now, I figures no way to speed this up/precompile (although I do believe that this is possible).
Database
I also did some projects with localization in database and custom <%#...%> blocks to load the languages.
Today, I would vote against this as it is non-standard. Although it would be probably just as fast to compile, no matter whether 1 or 50 languages are involved.
3rd Party Tools
You also could fetch a commercial product to do the translation, if I could afford, I would have done this most likely, too.
Just my two cent...
I am in the process of designing a web application which will have multiple installable modules that provide different functionality. There's a lot of common stuff going on here and I have 3 C# class libraries that I know will be easy to use on different projects.
The bit I am stuck on is the actual website itself. Ideally I'd like to make an ASP.NET page library that can be re-used over multiple projects but I understand that this is not possible.
How do you guys structure your website projects so that pages can be re-used across multiple projects? So far the only solution I've come up with is to create a repository in SVN and have it referenced in the svn:externals properties of the main project. This allows me to add pages to that directory that are common to all websites, and I know I will be able to use this to check them out to other projects. However, I feel this is a bit clunky and will cause problems when creating new projects (there'd be a number of steps to creating the new solution, ensuring that the right externals are in place).
Is there a better solution? What is the best way when you want to share common ASPX files across multiple client projects? How do you manage changes against them?
Thanks in advance!
EDIT:
Many thanks to David for his response. I've had more thought on this and thought I'd list some of my more concrete ideas/concerns. Firstly, a bit more about the project(s). Primarily, it's a CMS. However, we also have clients that will want CRM, and there's also clients that want neither and want an entire bespoke system from the ground up.
In my original post above, I spoke about having subdirectories of the main root (e.g, cms), using svn:externals to allow easy re-sharing of web pages across multiple projects. I am beginning to think this is the only way to do this. One thing that bothered me was if the client's url was:
http://www.shotgunanddribble.com/cms/content.aspx
However, I think I can use the Application_BeginRequest to mitigate horrible urls by rewriting them according to the configuration of the client's site. E.g, if a customer was just a CMS I could rewrite their Top-level-domain to /cms/. Same with if they were a CRM. If they were both:
http://www.shotgunanddribble.com/ -> /cms/
http://crm.shotgunanddribble.com/ -> /crm/
Is there any downside to using these kinds of rewrites? I think that, unless anyone else has any magical ideas, svn:externals is my only hope.
The actual code is easy enough to put in other assemblies and inherit from, but the ASPX files are definitely a different story. How about a common library of user controls to contain most of the display content, and each project would have its own pages which mostly just frame the user controls? I've never tried it, so there may be some "gotcha" that I'm just not picturing right now.
I'm inheriting a web application and the previous programmer compiled all his code into a .dll. The .cs files are not present on the server.
Working on previous projects, I've always uploaded the .aspx file and the corresponding .cs file. It's never been a problem for me and I always thought it was standard procedure. Am I wrong or just paranoid?
Will,I think this is quite common to keep code precompiled into dll. Then the code is less exposed for potential security holes. This provides also many advantages, which include faster initial response time, error checking, source-code protection, and efficient deployment. This is particularly important in large sites where there are frequent changes in Web pages and code files.
Leaving source code as a part of the project isn't necessarily the best source code management process. There are tools for that.
Also, precompiling source code isn't out of the ordinary (this is a Web Application project rather than a Web Site project in Visual Studio), and has many benefits.
Note that this doesn't make you wrong or paranoid.
There are good reasons for both strategies you just have to figure out what is going to work best for you environment and for the application.
In some ways it is good to have it precompiled if you worry about someone accidently making a change on the server but not checking the change into source control. With non-precompiled if you don't have change control on your server it can be hard to figure out who "accidently" made a change and why without checking it in.
On the other side, if you don't precompile it can make deployment more straight forward.
Just do a little research behind both strategies and decide what is going to work best in your situation.
As Nader pointed out, in a Web Application you don't need the CS files at all. There is not a huge risk of the source files being served accidentally, as protecting these files is a core function of IIS request management. Still, it is generally good practice not to deploy them to a production web server.
In any case, source files should at the bare minimum always be backed up in a location that is not the web server and should be source controlled whenever possible. I have seen too many websites where the source files were lost and the site was useless as a result.
Like everyone above has said, compiling source code into DLLs is considered best practice.
If you'd like to see the code of the DLLs you've been left with, there's a handy (and free!) tool called Reflector (apologies if you've already got it)
http://www.red-gate.com/products/reflector/
Just load up the DLL and then disassemble to view the source.
Web Application Projects compile into .dlls and leave no source on the server.
Web Site Projects deploy all the source to the server.
It's a religious war as to which is best. Google will present you with many varied opinions, so I won't press my own opinions on you.
We’re coming to a big release in a web project I work on, and I’m starting to think more and more about javascript/css performance and versioning. I’ve got a couple high level ideas so far:
Write (or customize) an http handler to do this for me. This would obviously have to handle caching as well to justify the on the fly IO that would occur.
Add these steps into a custom msbuild script that would be ran for deployment only.
I’m also looking at automatically generating config files for each of the servers I deploy to, which lends itself to the second idea. The major advantage I see with the first idea is that I could dynamically handle versioning (at least that’s what one of my links at the bottom says, I’ve yet to convince myself that this would actually work).
Anyway, I’m curious if any of these problems have already been solved. I’d love any feedback. Thanks!
Here are some resources that I've been looking at so far:
http://madskristensen.net/post/Combine-multiple-stylesheets-at-runtime.aspx
http://madskristensen.net/post/Remove-whitespace-from-stylesheets-and-JavaScript-files.aspx
http://www.west-wind.com/WebLog/posts/413878.aspx
http://svn.offwhite.net/trac/SmallSharpTools.Packer/wiki
You do this as part of the continuous integration build process you have.
Compare all JS to the previous checked inversion, for each that have changes, call out to the YUI Compressor on that JS file and name the output with the current revision number. Add that file to your repository, and change a config file to have the latest revision number for that js file. Then you will write a custom control that imports a js file. This control will either use the uncompressed js when running on a development machine, or the compressed file with the revision number from the config file when it is run on a deployed setup.
In addition for 1), Microsoft has built in support for embedding resource files into DLL. This will always get updated when your project is changed and recompiled.
The problem is, you don't have control over caching and file name. When debugging, it's hard to pick which one to debug when everything is called "webresource.axd" something. That was hell.
Would love to read how others do it, too.
Personally, I rather have it done as part of the build process as to avoid the performance cost of dynamically doing this on each request. I guess you can lessen the hit by implementing proper caching, but why bother... IIS can handle that for you already (unless you are not running on top of IIS, I guess).
As a general recommendation, things that Steven Souders talk about is also great if you want to speed up browser rendering. If you have not already, take a look at this.
My team recently moved away from keeping scripts as embedded resources and we are very happy with the results. Yes, you can combine and minify them using handlers, but it's a bit of a hassle, especially when you want to host them from a separate domain.
What we do now is we keep all of our control script files separated and then use a tool, like js-builder, during the build process to combine and minify them. We actually output two files from the tool, one simply combined for debugging, and the combined and minified one for production use.