Even now, with the project already ongoing, you can still set things straight. Put your project in source control. Then create a "master" branch that will contain the code released to production. Develop new features in a separate "develop" branch. If you need to fix something in production without updating to the version in development, create a new branch off "master", fix the issue, commit and release this new version, merge it into develop, and carry on.
A workflow like this, or other variations, is a good practice even if you work with platforms that support deploying single classes/files instead of packages.
C# is fine for web development if you're in an enterprise, and in fact, it's preferable.
The last thing you want is developers using production web servers as test/dev/qa environments, and it's all too easy to push code changes out to a scripted environment like python or php.
With the requirement that a build cycle occur, it slows developers down so that they don't make the idiotic choices many will, and use production systems for anything other than production web serving.
That said, I don't use C# for anything other than freeswitch and mobile development, and it's perfectly fine for that.
As others have said this is really a source control problem but still there's a workaround. Just copy the production dll and use .Net Reflector (or similar) to decompile it back in to C#. Make your edits, recompile and upload.
Sounds like the wrong project type is being picked. If they used a Web Site Project rather than a Web Application Project the files would be compiled JIT in the same way as PHP and Python.
Having said which the page title is wrong, the issue is with Microsoft's web deployment system and frameworks. C# as a language is still a nice language and shouldn't be lumped with the other parts of the .NET stack.
5 comments
[ 3.1 ms ] story [ 22.4 ms ] threadA workflow like this, or other variations, is a good practice even if you work with platforms that support deploying single classes/files instead of packages.
For an example, see: A successful Git branching model (http://nvie.com/posts/a-successful-git-branching-model/).
See also the book "The Pragmatic Programmer: From Journeyman to Master" (http://pragprog.com/the-pragmatic-programmer/extracts/toc).
Good luck.
And your excuse for not having the app under source control is a cop-out and shameful. Enjoy your scripting languages and short-cuts...
The last thing you want is developers using production web servers as test/dev/qa environments, and it's all too easy to push code changes out to a scripted environment like python or php.
With the requirement that a build cycle occur, it slows developers down so that they don't make the idiotic choices many will, and use production systems for anything other than production web serving.
That said, I don't use C# for anything other than freeswitch and mobile development, and it's perfectly fine for that.
http://msdn.microsoft.com/en-us/library/dd547590(v=vs.110).a...
Having said which the page title is wrong, the issue is with Microsoft's web deployment system and frameworks. C# as a language is still a nice language and shouldn't be lumped with the other parts of the .NET stack.