I've found that some of my ASP.Net web apps prompt the browser to load plugins that I'm not explicitely using and certainly haven't deliberately referenced in the project settings.
Two that come to mind are for MS MediaPlayer and the "SVG Viewer for Netscape".
The only commonality I've determined so far is that the two sites/apps affected both use Master pages (nested in some cases).
We don't use SVG file types (just the normal mix of jpg/gif/png) and no video/audio (not yet anyway).
Can anyone provide a hint as to where the references for these might be creeping in? e.g. Is it a server-level include? Or a .Net runtime default when using master pages?
Does anyone else even experience this, or is it just me?
No urgency, I'd just like to remove it if possible.
Thanks.
Al
If you look at the page source in your browser, you should see what's in the page that requires a plugin. If you load external Javascript, you will have to look at that too. Do you have ads on the site that include 3rd party code?
Related
I have a sharepoint at my office. Its 2013 version. Where I want to write some asp code. But the issue is SharePoint is blocking the code and I am getting error "Code blocks are not allowed in this file". I searched google and found several links to solve the issue by saying make some changes to the webconfig file.
Now my question is how do I find the file. Where it is actually.
What I have is a sharepoint, I don't have any designer. I only have admin access for this site. Can some one please guide me.
I know there are several entries here in stackoverflow, but no one is talking about where to find the file.
Please help me.
My apologies if this happens to be a repetition, in that case please point me to the right post. Thank you guys.
By default injecting server-side code (ASP.NET) in SharePoint pages directly from sites is not allowed for performance reasons, and should remain as is.
If you never approched SP developpment and are not an administrator of the farm in your company I strongly advise you to see first if you can solve your needs with client side development (javascript) instead of going to server side (ASP.NET).
SPS2013 comes with the "Script Editor WebPart" that you can use to inject your custom JS on pages. If you need your custom on all pages consider adding your JS on the site's masterpage.
From JS you can use SharePoint REST API to interact with your site https://learn.microsoft.com/en-us/sharepoint/dev/sp-add-ins/get-to-know-the-sharepoint-rest-service
If you need heavy customisation for your site you can move to the addin model (client side) that will require Visual Studio IDE develoment suite.
And last option is if you explicitly require serve side code and/or need to develop a scalable enterprise grade solution, you will need to make a "SharePoint full trust solution package".
PS: You may see articles around about "SharePoint Framework" (aka SPFx), unfortunatly this is not available for SPS2013.
Recently I've been working on a big ASP.NET Web Forms site and it has some pages that apparently are not in use anymore, but no one knows for sure (this is an inherited project). Is there a way to know if those .aspx files/pages are being used or referenced?
This is not a Web Application Project but a Web Site Project; so I guess it's more difficult to find what .aspx pages are being used and which ones are not. if anyone has experienced something like this, what was your approach to clean this up?
No, probably not. What would be the criteria for that, if no one knows for sure? If you developers can't tell, how would some automatic system decide this for you? You don't need to have .aspx referenced in code for them to be used.
You can use search function in VS to find references inside the project, but in a big website like yours it might be kinda slow and problematic. I'm afraid you'll have to go page by page and figure it out by yourself.
I am developing a drop-in component for our company's websites. This component allows users to send messages to each other.
Making this, I've hit several problems during development, such as LoadControl() not working (as it seems to be relative to the project including the module, not the module itself).
I managed to fix this using an approach I found online, but now the next problem emerges - images.
To make the component look somewhat nice, images would be appreciated by the users for icons.
But, again, I am stuck at the same problem.
For instance, if I want an ImageButton, I would set it's ImageUrl property to "~/images/message.png", but this really references something inside my DLL and as such obviously doesn't work!
Is there a standard, good solution for this kind of problem?
Thanks!
You could use WebResources, look at
http://www.aspcode.net/Including-WebResource-in-ASPNET-server-control.aspx
or embedd image in control assembly as resource and serve it with http module, but you will have to declare that http module in web config of application that is using your control.
I've been doing the html and css for a site, sending it off to a guy to implement in a web server. I get a call from the designer freaking out about the progress, saying the clients aren't happy. He wants me to personally integrate my css with what's on the site. The site is done in ASP.net, time is short, and I'm a little in over my head. I have an understanding of how php works, but have never worked extensively with it.
Looking at the stuff on the ftp, I can't even find equivalent of the index.html file (I know that when I go to the site itself, there is nothing after the base url, i.e., www.site.com/ brings me to the homepage.)
Can anyone give me a few tips or links as to what I am to do with this, or where to even being navigating this site?
EDIT: It's -not- a .Net Web Application, from the looks of it.
ASP.Net can be run in a compiled or a scripted environment. It is important to understand which environment your client has. If it is completely scripted, then you are likely looking for the default.aspx file and it's contents. If it is a compiled environment, you may be in for a ride. A compiled site may incorporate "master pages" as a templating engine, and then you'll need to apply your html/css modifications in several places.
You should start with the default.aspx page if there is one. Look for master page directives (it'll be named something like masterpage.master). If there isn't one, then you're in luck you'll just need to implement your changes on a page by page basis. The aspx page will be in a templated xml format so avoid touching tags that involve touching
If you are making changes to divs and structures of that nature, you may need to modify the CssClass attribute of the controls. I would recommend however that you make a back up, give it a shot, and under no circumstances attempt to do something that you aren't really ready to do. You will only anger the client and ruin your rep. It may actually be prudent to contact an actual ASP.Net developer to analyze the files separately and determine what you need to do.
I suggest that you read the Wikipedia article about ASP.NET to get familiarized with it as it summarizes the basic building structures.
Then, just to get you started: take a look at the more recent ASP.NET MVC (Model-View-Controller) paradigm. There's also development in what is called ASP.NET WebForms.
For example: when you go to www.site.com/ (known as friendly URLs) it may be redirecting you to an action method inside a controller. It's called routing. There's also URL rewrite.
In the MVC world a Controller can send/redirect the user to a specific View/Page.
A View (.aspx form/page) that contais HTML markup and CSS on the server side is basically an HTML page (.htm) page that'll be rendered on the client side.
I've recently started embedding JavaScript and CSS files into our common library DLLs to make deployment and versioning a lot simpler. I was just wondering if there is any reason one might want to do the same thing with a web application, or if it's always best to just leave them as regular files in the web application, and only use embedded resources for shared components?
Would there be any advantage to embedding them?
I had to make this same decision once. The reason I chose to embed my JavaScript/CSS resources into my DLL was to prevent tampering of these files (by curious end users who've purchased my web application) once the application's deployed.
I doubting and questioning the validity of Easement's comment about how browsers download JavaScript files. I'm pretty sure that the embedded JavaScript/CSS files are recreated temporarily by ASP.NET before the page is sent to the browser in order for the browser to be able to download and use them. I'm curious about this and I'm going to run my own tests. I'll let you know how it goes....
-Frinny
Of course if anyone who knew what they were doing could use the assembly Reflector and extract the JS or CSS. But that would be a heck of a lot more work than just using something like FireBug to get at this information. A regular end user is unlikely to have the desire to go to all of this trouble just to mess with the resources. Anyone who's interested in this type of thing is likely to be a malicious user, not the end user. You have probably got a lot of other problems with regards to security if a user is able to use a tool like the assembly reflector on your DLL because by that point your server's already been compromised. Security was not the factor in my decision for embedding the resources.
The point was to keep users from doing something silly with these resources, like delete them thinking they aren't needed or otherwise tamper with them.
It's also a lot easier to package the application for deployment purposes because there are less files involved.
It's true that the DLL (class library) used by the pages is bigger, but this does not make the pages any bigger. ASP.NET generates the content that needs to be sent down to the client (the browser). There is no more content being sent to the client than what is needed for the page to work. I do not see how the class library helping to serve these pages will have any effect on the size of data being sent between the client and server.
However, Rjlopes has a point, it might be true that the browser is not able to cache embedded JavaScript/CSS resources. I'll have to check it out but I suspect that Rjlopes is correct: the JavaScript/CSS files will have to be downloaded each time a full-page postback is made to the server. If this proves to be true, this performance hit should be a factor in your decision.
I still haven't been able to test the performance differences between using embedded resources, resex, and single files because I've been busy with my on endeavors. Hopefully I'll get to it later today because I am very curious about this and the browser caching point Rjlopes has raised.
Reason for embedding: Browsers don't download JavaScript files in parallel. You have a locking condition until the file is downloaded.
Reason against embedding: You may not need all of the JavaScript code. So you could be increasing the bandwidth/processing unnecessarily.
Regarding the browser cache, as far as I've noticed, response on WebRecource.axd says "304 not modified". So, I guess, they've been taken from cache.
I had to make this same decision once. The reason I chose to embed my JavaScript/CSS resources into my DLL was to prevent tampering of these files (by curious end users who've purchased my web application) once the application's deployed.
Reason against embedding: You may not need all of the JavaScript code. So you could be increasing the bandwidth/processing unnecessarily.
You know that if somebody wants to tamper your JS or CSS they just have to open the assembly with Reflector, go to the Resources and edit what they want (probably takes a lot more work if the assemblies are signed).
If you embed the js and css on the page you make the page bigger (more KB to download on each request) and the browser can't cache the JS and CSS for next requests. The good news is that you have fewer requests (at least 2 if you are like me and combine multiple js and css and one), plus javascripts have the problem of beeing downloaded serially.