When I run the site using the normal debug feature of Visual Studio, a lot of images go broken and formatting seems messed up. However, when I deploy the site, it all seems fine.
What could be the reason? As long as it looks good deployed, is it safe to ignore the formatting issues that come up with using undeployed websites?
Note: I am using same browser for both deployed and undeployed website.
My guess would be image and CSS paths. Perhaps they are relative? Definitely need more information (code) to give you a solid answer.
EDIT: A good way to troubleshoot this would be to right click on the image while debugging and copy its address. Then right click on the image when deployed and copy its address. Compare the two addresses and you might spot something obvious like a path problem.
What are the exact paths of your deployed and undeployed web sites?
You probably have images and CSS files that are referenced using a path that only works on the undeployed web site.
Try loading the deployed web site while running Fiddler and checking which URLs generate errors.
How exactly are you referencing the images and CSS files in your ASP .Net source?
Reasons are addressed by Mayo - but to answer the other question:
No, it is absolutely not safe to ignore the issues unless you have a very clear understanding of why they arise at which point you may be able to choose to not worry about them (although I'd probably not be particularly happy to have to so do).
There are reasons why it may not be practical but pragmatically I require that we can pull a project from version control, build and run and it more or less should run pretty much as live (there are a few caveats about meeting requirements for installed stuff and any necessary config) - certainly I'd expect the appearence to be right.
I would guess that you have some errors in your image paths. Try checking the resulting HTML with for instance Firebug(which is awesome!) to see if the path is wrong.
Maybe like Mayo say, probably the path.
Are you using ~ before your path ... like ~/_images/myImage.jpg or _images/myImage.jpg.
Most of the time, it happens because the ASP.NET development server start your application as a website and you probably deploying on iis in a virtual directory (as an application). So path beginning with / will not react the same way.
As suggested by Cédric, you can start your url with ~ but only if you're using a server site control (like asp:image) or an img html tag with runat="server".
For CSS, javascript or any regular html, you must make sure that all your resources are relative to the page.
I3dx give a good suggestion using firebug to track the faulty url.
Hope it will help
Related
I'm really keen to use the 2sxc environment on my website for a number of applications.
I'm currently looking at the Mobius forms.
What I'm wanting to do is create a ticket in ConnectWise rather than send an email, using the ConnectWise REST API.
Some of these questions might have obvious answers to someone who has been taught in these technologies, but I'm self-taught. When I went to school I learnt COBOL!
There is c# code in the application, but I can't see how you build and incorporate into the application. I forked the code and it seems to just code with no build.
There are live and staging folders with the same cshtml files. However, it seems a bit random when the live or staging is actually used. For example, I did a quick fix to the _Contact Form.cshtml so to fix the type that meant it always displayed the ReCaptcha warning, and I changed the live version, which didn't do anything, so I had to change the staging version.
I need to update the settings so that configure the ConnectWise API settings, I haven't been able to find where I can do this? I am still looking though.
I also need to store a private key in the settings. Is there a secure way I can do this?
PS. When I get my head around all this I'm happy to be a contributor
welcome to StackOverflow.
I'll try to give you some guidance to help you figure it out
Live and staging are folders meant to let you make changes while the users see the unmodified output. So a host-user sees the files from staging, others see what's in live. When you're done and all is tested, you copy from staging to live. This we call Polymorphism.
Polymorphism applies to both the cshtml as well as the api. So as a host-user, you'll be using staging/api/FormController to save/send.
There is no build process, everything is hot-compiled. That's one of the things that makes 2sxc so amazing. No Visual Studio, DLL or restarting the application ;) You'll love it.
Secure keys: there is no special secure key storage. We usually put it in the App-Settings, just like the MailChimp key you'll see there. We split it into two fields for very technical reasons, because we publish our code on github and that causes trouble when our code has API keys. But you can just use one field, assuming you don't plan on publishing the code on github.
I was recently asked to create a web page using a static website generator, like Jekyll. My question is this:
How does this differ from just creating a website using HTML or writing the page as an ASP.net project in Visual Studio?
How does it work on the server?
What are some concerns I should have?
I'm a .net guy, so I would like to be able to create this in visual studio, if possible.
Here are some advantages and disadvantages that came to my mind:
Advantages
can be deployed on every server, as it's just static html
has partials, that can be reused, in contrast to normal html, where you have to code/copy paste every thing
you can still code in an IDE
a non developer can edit code (sometimes at least)
Disadvantages
the template language is limited and sometimes a bit awkward/needs to get used to
you have something new in your environment, which has additional costs (more than one developer needs to know how to build the site, ...)
If you know your current toolkit well and you do not have a problem hosting another ASP.net project on your server, I do not see the need for you to introduce another tool in your tool chain.
If you want to do something, where users can generate content - like github does on the github pages - this is something you might consider.
As for Jekyll, we tried it on one project and being devs, who like to code, we ran into it's limitations quite early. You can work around this, but if you know a programming language you will be faster. It was still fascinating, how far we were able to go with just using Jekyll
With ASP.NET pages exist throughout the life cycle of the page, and able to work with request and session context. See this article asp.net page life cycle
HTML pages are static and you can not access any variable that is on the server.
I recommend you follow the step by step this link to go to just understand how to develop ASP.NET http://www.asp.net/get-started
I hope that helped
Vicente
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.
it seems that I just solved my problem why I couldn't use the ASP.NET Configuration Tool in VS2008. It seems this tool doesn't work when the aps.net solution is located in a folder containing special characters - spaces for example. Actually, I didn't discover this myself. I found it on various forums.
What puzzles me though is that my VS2008 puts new projects (web projects included) into my documents folder which deep down at the root starts with Documents And Settings\[User]\Documents (on XP at least). Am I missing something here or does the default really makes using the ASP.NET Configuration tool impossible to use?
Thanks for you feedback
There is very little I use the ASP.Net Configuration tool for anymore (all it does is modify your web.config), and a lot of things can flub it up, but...
Most of my projects have spaces in the path at some point, and I've never had any trouble with that part.
My advise would be to figure out what it is that you want to do, and learn how to make that change directly in the web.config. (I can hear the down-modding as I write this)
I have a requirement on my new project to serve up some "hidden" assets (actually just stashed in the App_Data directory) after a certain date. Before then, they should act like they aren't there.
I've done this kind of thing a hundred times with Page object, but as I started work on this, I thought I'd look into handlers. Having never worked with them (and being a little intimidated by them), I was happy to find that they'd serve up my XML and JPG files without the overhead of the whole Page class. Already, I'm happy that I considered it. I wrote it to handle functionality like "MyHandler.ashx?secretfile=blah.xml", and it worked great.
Then I started looking at special extension handling, so that a request for "blah.xml.secret" would get picked up by handler and return blah.xml after checking the date. A couple of lights went off in my head, and I reworked the code so that it handled that case. It worked (in the IDE)! I was pretty excited.
Getting it onto the dev server (IIS) was a little different: I had to register .secret as a .NET type (no big deal), and it still didn't work until I unchecked the "verify file exists" checkbox. (blah.xml.secret obviously doesn't exist: blah.xml does, but not in the spot it's being asked for, only in the secured App_Data directory.) That's not a huge deal, but now my clever solution relies on two implementation details from the IIS side.
So my question is: is this the intended use of handlers in asp.net? Am I warping this beyond recognition? I feel like I've seen sites do tricks like this in the past, but for the one thing I'm trying to do, the IIS changes seem overly complicated. In my research on this, I didn't find a slam dunk 1-2-3 guide to using handlers that included an example like this, so it's got me thinking I'm maybe abusing it or going about it the wrong way.
Yes, that's pretty much how it works. (In Windows Server 2008 there is a remote chance that you can do the settings from web.config so that you don't have to change anything in IIS.)
If you use an extension that isn't already registered to be handled by the ASP.NET engine, you have to register it. If you use an extension that already is handled by ASP.NET, like .aspx, then you don't have to register anything in IIS. (When you run it in the integrated web server in Visual Studio, everything is already handled by ASP.NET, that's why it works there.)