I'm working on a system that embeds various JS and CSS resources in the project dll, and access them using WebResource.axd. This all works fine locally, but if I download and install the app from our nightly build server, all our WebResources report a 404 error.
We initially though it was because the downloaded zip file was blocked, and for a while, unblocking the downloaded zip before extracting did work, however, now, nothing seems to work.
Swapping the downloaded dll with the one created locally makes the WebResources work, so it sounds like something is going on with the dll (either on the download server, or during the download process).
Anybody got any ideas what it might be?
So I managed to find the culprit myself, which was that the Modified Date timestamp on the DLL's was set to the future (our build server is in a timezone one hour ahead of ours), so for some reason WebResource wasn't picking them up.
Hope this helps someone in the future.
This normally occurs if you are using AJAX/3rd party controls. Most probably it is not a problem of missing WebResource.axd but some other reference / resource pointer is missing. Try debugging using the information provided on this site
Related
I have deployed an application on meteor.com long ago, I have lost my files and I currently have no way to continue the project except starting again from the scratch.
How can I download the complete project.
Thanks in advance.
Depending on how big the project was, I don't know if you'd be able to get the code back. However if it's small enough, here's an example:
http://todo.meteor.com/ - View the source, there will be a script with the source file (all of your meteor app). since you only need the code you wrote it will be at the bottom of that file.
Use something like this and see if you have any luck.
Bit of a weird one. For some reason one of my DNN modules keeps being converted into an Application in IIS7 in my development environment. Meaning when I try to view a page that contains that module it can't find the module correctly. It's ok if I go into IIS and delete the application, then restart the site but is a bit of a pain and am little worried it might do this when uploaded to the live server and disable the whole site.
Anyone encountered anything like this before? Any thoughts?
This is a common problem with my VS templates, though not for everyone, and it doesn't happen all the time. It stems from Visual Studio, so it shouldn't ever be a problem on your production servers, unless you upload source and try to compile there, than it might be an issue.
HuwD,
A good resource might be my module template installation video which gives good information on setting up your development environment and debugging issues (regardless of the template you use). Check out between 1:30 and 5:00 minutes for the environment setup, and after 19 minutes some of the troubleshooting.
A couple common problems I see Visual Studio doing is creating an unwanted virtual directory on the DesktopModules folder and/or creating an unwanted web.config in the module's root.
Another good resource is Dnnhero.com. In the development section there is a series on DNN7 environment and template setup.
You may want to give a try a free module called Users Importer - A bit old but worth a try.
Here is a paid alternative: Bulk User Manager
I'm having a real hard time with what seems to be a rather old bug (pre-2009) in the Windows Azure platform. In short, after deploying to Azure I get HTTP 404 responses for JavaScript resources loaded via WebResource.axd. This is a big deal since it breaks most of the AJAX functionality on the website. The interesting part is that things get normal about 2 hours after the deployment and the 404-ing resources start loading normally. And the event more interesting part is that the 404 errors don't occur after each deployment.
After a lot of Googling around I found a similar case on the Azure forums. Yi-Lun Luo's last post makes me think the problem in my case is related to the bug he describes. Maybe I'm wrong, but there seems to be a connection between the 2 hours it takes for the 404 errors to cease and the fact that my timezone is UTC +2.
Please, if anyone has had a similar problem or has an idea for a workaround, let me know. I would be really grateful!
We have run into this before on another project. It's actually not an Azure problem at all, but rather a bug in how the WebResource.axd is loading the assemblies (roughly speaking). The problem is related to the timezone. If the binaries you are building and deploying are in a timezone "ahead" of the timezone you are running the code in then you will run into the problem you are seeing. We specifically ran into the issue when dealing with a control from Telerik. We reached out to Telerik for help and they had some suggestions on thier site.
Basically, you need to "touch" the assemblies you build so that the last modified date is a time prior to the current time in UTC. The link uses this syntax (note commas are important):
copy /b <path to assembly which is built in the future>+,,
The build server was in the Eastern Time zone and the production servers were in the Central Time zone. We would copy the binaries to the production box and perform the command above on them. You could mimick this in Azure with a startup task and that should do the trick.
We recently migrated from VS 2008 to VS 2010. The migration went fine, except for our web project. Before, in VS 2008, the site showed up as http://localhost/Website. Now, it appears as C:...\Website. It appears that when we did the migration, VS started to treat it as a file system website.
I've tried removing the existing site and re-adding it as an existing website, but it still displays it as C:...\Website. Is there any way to convert it back to show it as a http://localhost/website, and run through IIS, as opposed to the default ASP.NET Development Server?
Special thanks to John Dundon at Microsoft for helping me resolve the issue. Here's what he said:
Thanks for all the details. This actually sounds like a quirky behavior
in VS that I think I can help you work
around.
I believe the reason it’s remembering
to use the local development server is
because it got stored in the SUO file.
So there are two possible ways to fix
this:
Re-open your solution from source control as an administrator on the
machine with IIS installed and
everything should get downloaded to
its right place
If you close VS, delete the SUO file (note – this will erase some
settings about the state of your
solution but shouldn’t cause any real
data loss), and then re-open the
solution, it should ask you to
re-download that particular web site
and will try to make it an IIS web
site again.
Note however though that since your
virtual directory already exists on
your machine, it’s going to ask you if
you want to use it – I’m assuming you
do, but it will overwrite any files
when it does.
Let me know if this works for you (and
while you technically shouldn’t need
to, it may be a good idea to back up
any work you’ve done in this
enlistment that hasn’t been checked in
prior to trying this).
I followed his advice and removed my SUO file and re-opened the solution. The website was automatically fixed as http://localhost/Website and it also checked out the .SLN file as well, and when I checked it in, it fixed the issue for other developers as well. Hope this solution helps out others as well with this quirky issue.
Look in the project properties, on the Web tab. You'll be able to select whether to use IIS or the development server, and which virtual directory to use.
I have a pretty weird situation here, and i came up with a very strange conclusion, the thing that makes me think that i got it all wrong, that i have cured the scratch with hcl or something !
Anyways, two days ago i found out that all the pages in a certain directory on a web app that I work on stopped working;
When I tried to debug, iis shout out an exception at my face, the exception was kinda weird (and very ambiguous to me), it says
"type Global is declared in an
assembly that is not referenced here"
and the cursor pointed to a line of code in the generated asp.net temp files, so i checked up my bin directory and compared the live version (the broken version) to my own local version (the working version) and found a couple of dlls missing on the live version
i copied those dlls from the local to the live, and everything went just fine!
the question is, where did files go in the first place, and if the temporary asp.net files were corrupted, is there is any way to fix them without having to reinstall the framework, or rebuild the app?
The Temporary ASP.Net files are created whenever your web asp.net app has to compile. (If you search this site or Google, you will find many descriptions and information on how this works.) They can be safely deleted at any time, so long as the original files are available to recompile. No reinstallation of .NET framework needed.
I doubt that anyone is going to be able to tell you where they went. Your best bet is to put some auditing on the files and log the deletes to the event log.
Its possible that ...
someone else who has access to the server deleted the files accidentally or on purpose.
you deleted them accidentally
you were hacked
your files were deemed viral and were quarantined by an anti virus.
Probably a few other reasons I cant think of too...