Should we be able to just reference the Telerik DLLs within our project, set the Output Local to TRUE and be done with it? Things work perfectly on our development machines where we installed the entire Telerik Control Suite but when we deploy, we have a problem in which Telerik controls within UpdatePanels don't seem to be firing events.
If the controls are rendering on the deployed environment without an error, then the necessary .dll's are at least being referenced somewhere.
However, if you have them installed in the GAC, and your reference is to the GAC, then "copy local" might not be doing anything... they might just be copied, and no one is even referencing them.
Can you double check that all your references are local references, and there aren't different versions installed on the GAC on the two machines?
I would look a the .dlls being outputted and those that are on your machine. I bet there is a .dll that it is looking for in the GAC that is not on your production box.
On a side note, why not just use the ASP.NET Ajax Update Panel?
First a little disclaimer - I work for Telerik :)
This is really a strange case. Could you check for any JavaScript errors on your production environment? I suspect there is some deployment issue (for example web resources not configured properly). In case there are JavaScript errors you can check my blog post which explains how to deal with the most common cases.
In any case I recommend you open a support ticket (if not already).
My problem had to do with an HTTP Module we had running for URL encryption. I have found, however, it is best to NOT combine asp:UpdatePanel and RadAjaxPanel in the same pages.
Related
I'm working on an straight ASP.Net application. (no additional frameworks).
I've got several user controls (not custom controls) which I'd like to be able to package into a DLL for reuse/redistribution across several other applications. Ideally, we'd like to have everything self contained in (.ascx and source files) a DLL which could be added to the target project's references.
When embedding the user controls into .aspx pages, we'd like to be able see those controls in Visual Studio design view.
I've been looking around and seen several possible solutions for this.
Can anyone point me to a clear tutorial/example which will help step me through this process?
John, as far as I am aware, what you are asking is not possible, at least not out of the box with the .net Framework. When you build a UserControl in ASP .NET app and compile the solution, as you may have realized, the UserControl would be included in the dll of the project to which it belongs; it won't have a separate dll of its own. Since the UserControl won't have a dll of its own, you won't be able to make it available in the design view/toolbox.
For what you are asking, you might want to consider creating ServerControls instead. Server controls are harder to create than UserControl, if I recall correctly, you have to code it entirely, wont have designer available, but when you are done and compile, ServerControl will have it's own dll, which could be made available in CustomControls under Toolbox.
If you want a starting point for ServerControl, I would highly recommend watching the video from KudVenkat. His explanation and demos are second to none.
Link to the tutorial
I know that in order to use most of the controls from the Ajax Control Toolkit, you need to include the ToolkitScriptManager control on your page, and it must be the Toolkit script manager, and not the standard script manager because the extended toolkit version contains extra (java)scripts which enable the controls to work and communicate properly.
My problem is that I keep coming across projects at work from other developers where they used the standard ASP ScriptManager control, and added toolkit controls without switching over to the ToolkitScriptManager. I would have expected these projects to not debug properly, yet they are currently somehow working in test and production environments, and they do not actually break until I download them onto my freshly loaded dev environment from source control.
When someone asked me "Why do we need to replace these controls? They're working everywhere else." I could only shrug my shoulders, I have no idea why other projects are working with regular script managers.
As a side note, problems like this are what are pushing me into becoming a JQuery guy instead of a ACT guy.
Here is a question to answer since this is a Q&A site and not a discussion site: "How is it possible to run the ACT controls without an ACT script manager?" Personally, I would point to a glitch in Visual Studio of some kind, but I want to know if anyone else knows more.
ToolkitScriptManager inherits from ScriptManager and extends/improves its functionality.
You may safely substitute ToolkitScriptManager with ScriptManager just so long as you are not using any advanced feature provided by the ToolkitScriptManager.
What are those supposedly advanced feature differences you ask?
Check Here for your answer...
TMI Alert:
MS actually recommends replacing ToolkitScriptManager in certain instances if you are suffering from Out Of Memory exceptions and there are also a high number of System.Web.FileMonitorTarget objects in existence. These objects are used to check and see if the page was modified (you can see how it relates to AJAX), but these objects should go away and not be maintained.
For some reason, if you're using the ToolkitScriptManager, there are instances where FileMonitorTarget objects just don't go away and end up contributing to server memory problems, but neither I nor they fully understand why replacing the ToolkitScriptManager with ScriptManager actually helps in these scenarios, but just so long as it works, we won't continue to ask questions...
I have looked through the related questions, and none of them have provided me the information I am looking for.
Currently the team I work on does deployments of individual .aspx (and .aspx.vb) files for bug fixes/enhancments. I am trying to affect change, as I really believe that deploying the "whole compiled site" is less error prone. As this is a significant change from the way things have been done, my suggestions have ben met with significant resistance.
As my google-fu has not been up to par lately, I was hoping the SO community could either tell me that I am off my rocker, and that there is nothing wrong with moving individual files, or point me to some really good resources which would allow me to make a stronger case.
Edit:
This has all been great info, and reinforces the arguments that I have already been making, can anyone argue the other side?
Deploying individual files for bug fixes and deployment is not a wise strategy. It sounds like you need a comprehensive build and deployment process. That doesn't mean it has to be complicated as there are some good tools available nowadays.
Build and deployment can get detailed, so as a minimum start try taking a look at the Microsoft Web Deployment Tool (http://www.iis.net/extensions/WebDeploymentTool). Install the tool on your build server and install it on your deployment server. Stage your ASP.NET content locally using the Visual Studio Publish command, then use the above tool to synchronize the entire package on the deployment server. I like this approach because it can be completely automated. When doing builds and deployments, aim for complete automation to reduce potential errors.
This is the bare minimum, but you will at least be certain that when specific files are changed, they are ALL synchronized on the deployment server.
Personally to me rolling back immediately is most important. Again website projects are very hard when it comes to track the changes.
you can find a good detailed comparison here. I am reproducing the article here.
1) Deployment. If you need in-place deployment, this model is perfect. However, it's not recommended since you are exposing your logic in clear text. So, anybody who have access to physical server can mess with your code and you never going to notice this. You can try to make precompiled web site, but you going to end up with a lot of dll and almost untouchable aspx files. Microsoft recognized this limitation and released Web Deployment Project tool.
2) You need to keep track of what did you change locally and what did you upload to production server. There are no versioning control. Visual Studio has Web Copy tool, but this tool fails to help. I had to build my own tool, which kept track of changes based on Visual Source Safe.
3) When you hit F5 for debug execution it takes merely 2 minutes to compile and execute whole project. Of course you can attach debugger to existing thread, but this is not an obvious solution.
4) If you ever try to generate controls on a fly you will hit first unsolvable limitation. How to reference other pages and controls. Page and control compilation happens on a per directory basis. On best case you going to get assembly for each directory, in worst each page or control is going to get its own assembly. If you need to reference another page from a control or another page you need to explicitly import it with the #Reference directive.
So for,
customControl = this.LoadControl("~/Controls/CustomUserControl.ascx") as CustomUserControl;
You need,
But what if you want to add something really dynamically and can't put all appropriate #Reference directives? Or What if you are creating server control and it doesn't have ascx file, so you don't have a place for #Reference ? Since each control has it's own assembly, it's almost impossible to do reflection.
Web Application Projects which re-appeared in Visual Studio 2005 SP1. They solves all issues mentioned above.
1) Deployment. You get just one dll per project. You can created redistributable packages and repeatable builds.You can have versioning and build scripts.
2) If you did code behind change you can upload just one dll. If you did aspx change you can upload just aspx change.
3) Execution takes 2-3 sec maximum.
4) Whole project is in one assembly, which helps reference any page or control. Conclusion. For any kind of serious work you should use Web Application Projects. Special thanks to Rick Strahl for his amazing article Compilation and Deployment in ASP.NET 2.0.
I agree with Rich.
Further information:
Deploying your SOURCE code ala the .vb files to the server is a BAD idea. Compile it. Obfuscate if you can, just don't deploy straight source. Imagine an attacker which gains access to the system. They could easily change your code and you might not ever notice. Yes, you can use a tool like reflector to decompile. But it's really hard to decompile a full site, make the changes you want, and put them back into production.
Deploying a single file might very well cause some type of problem in a related module. I'm guessing you guys don't really do QA. Tell them it's time to grow up.
Compiling your site will reduce JIT (just in time) compilation. Think performance.
I'm also going to guess that pretty much everyone has production server access. This is bad from the company's perspective as you have no controls in place. What happens when an employee decides to cause some havoc before leaving?
What you are describing is inline with Cowboy coding. Sure, it's fun to ride to the rescue but this style frequently blows everything up.
It's bad for rolling back. If you deploy as a web site vs web app, yeah you can do quick patches of one or two files, but what if you ever need to roll back to a previous version? Good luck tracking down all the files that were updated to make the new version. I much prefer the concept of a "version" for organizational reasons, and the compiled web app is much more inline with this than a "website" project.
We had this dilemma and ended up going with the compiled version mainly for the security reasons. If your site is external facing you could be compromising your security by allowing the vb files to be out there in plain text. I realize one could still get your code if they really wanted to but it would be an additional hurdle they would need to go through. If you use Visual Studio as your development environment you can publish the site pre-compiled and check the named assemblies option when publishing and this will essentially create a dll for each aspx page so you can do the one off page changes if necessary. This was a great feature we found as we were constantly updating the whole site and there were times when things would get updated that shouldn't. After using that feature we no longer had updates getting pushed that shouldn't. As far as rolling back I hope your using some type of Source control / versioning system. Team Foundation Server is great for versioning/source control but it is quite pricey.
What is the best deployment strategy depends a lot on what kind of environment you are working in, and what kind of developers you are working with.
Visual artists that started with graphic layout and worked towards programming are much more in tune to individual page generation and release. Also the .aspx.vb files are simply server side scripting, not really programming.
Programmers usually start at the command line and branch out to environments such as the web and understandably feel that good programming practices should be applied too the web, including standard test and release cycles (and compiled code).
If the site is in constant flux the individual pages would make more sense, but if you are required to deliver an installation package to your production group msi files are the way to go, since they can be easily backed out if necessary.
If you evaluate what your groups needs are, which includes the varied experience of everyone in your group, you should be able to convince either yourself or the group. This is not a matter of which is better, but which provides the best business model.
If you distribute a .net web application, and you want a certain module of the application to be disabled, AND you don't want to ship the source with it, is it a reasonable solution to just not include the necessary .dll for that module?
I know you can do things programatically, but as long as you don't ship the .dll things should be ok right?
Reason being some .dll's require you to sell the product commercially, and if I want to give it away for free or as a demo I am stuck.
You have to go for plugin architecture. There's plenty of questions here on SO, as well as MEF which will be used in Visual Studio 2010, plus loads of DI/IoC containters which can aid in creating plugin-based apps.
You should be okay as long as the binary image you do ship doesn't actually need anything in the dll you're not shipping. That includes "does not expose functionality provided by the missing dll's".
For example; don't expose the "download as pdf" button if your pdf tools aren't "installed".
I've done this before by having a sort of plugin system that scans a predefined directory for .dlls and building a list of all exposed classes implementing a certain interface. Might be overkill for what you want though, and it's kindof the other way around than you suggest.
One possible approach (assuming you don't want to or can't go the plugin route) would be to create a dummy DLL with all the same classes and methods in there but that actually doesn't do anything.
Depending on the size and complexity of your DLL this may or may not be a viable action.
The plugin route would be the way I'd approach it though, as whenever the "real" DLL changes you will need to update your dummy one.
You definitely need some kind of 'in code' element, because a lack of DLL will break things in a worse way than simply disabling the modules you had intended.
This will definitely break if you are using Web Site instead of Web Application Project, because the DLL reference must be in your web.config... which will throw an error when it's missing.
You could get away with it in a Web Application Project, but that's a pretty ugly method. Much better to use some sort of plugin architecture, as others suggest.
Do you guys know about an ajax toolkit (or something similar to the m$-ajaxtoolkit) for mono??
Microsoft's ASP.NET AJAX Control Toolkit works on Mono, and is open source (Ms-PL). That doesn't preclude the use of jQuery, though. There are actually several third party AJAX libraries and control toolkits that support Mono, and many are compatible or work in conjunction with ASP.NET AJAX.
I agree with Brian, but want to add that you should read Dave Ward's series on jQuery and ASP.net. He really distills the essence of what you can do with jQuery, PageMethods, and WebForms without MS Ajax. These ideas are directly applicable to the Mono / Linux environment.
Here's a list of essential posts:
Using jQuery to directly call ASP.Net Ajax PageMethods
Use FireBug To Learn jQuery
Simplify calling ASP.NET Services with jQuery
I'd recommend rolling your own using jQuery. That's what m$ is doing now anyway.
Debugging Mono website
Do you remember, that you have no development environment in this machine? You can install it, or download Mono liveCD with openSuse. But before doing it, please note, that GTK# (it’s devenv) is not very user friendly. It even worse, then Eclipse. So let’s try to understand first whether we can fix small compatibility problems without entering code.
The most convenient method to debug web site on Mono is by using XSP and XSP2 mini web servers. Just enter the directory of the site and run it. By default you’ll be able to access the site by using ... (it also be written for you). Enter and notice whether you have any errors in console. No? Keep doing
The most common problem is “error 500” with nonsense stack. If it contains ScriptManager error Type not found, the problem is in Web.config file. Try to regenerate it to be compatible to Mono (for example, Mono has different version of System.Web.Extensions assembly. In ASP.NET 3.5 it has version 3.5, Mono has only 1.0.61025.0 (the old AJAX.NET). To recreate your web.config all you have to do is to execute “mconfig af AJAX Web.config” It will create default web.config file, supports System.Web.Extensions (AJAX features).
Not helped? Keep doing. Let’s look another time into the stack – if it contains errors in “EnablePageMethods” or “ShouldGenerateScript” or “EncryptString” – the problem is serialization. Mono has very limited support for JSON, XML and SOAP serialization. Try to look into your code and notice if you have classes, marked with [Serializable] or you are transferring your own classes by using PageMethods. If so, replace it with regular strings (my grandma serialization).