The company I work for, we have a number of web systems that are built in Classic ASP and ASP.NET 2.0.
I'm trying to tidy up the scripts folder as they are all sitting in the same place, and I've found some that are not even in use.
So, do any of you know if there is an easy way to generate something like a source code map? So I can easily see which one are not being referenced by any other script to make it easier to clean?
Also if I can generate this map, it would be great to start documenting this. As the previous developer was against documenting (believe it or not), and this is giving me lots of headaches.
Don't know if such tool exists but you could write a script that walks all files and searches in the contents of the sourcefiles if it is being loaded and not commented out (the last being the most difficult).
An easier way that i myself use is to load the different pages that are used in the webapp in Firefox with the Firebug add-on installed and activated (or a equivalent browser with the same functionality or plugin). On the Net tab of Firebug you see all the files that are loaded by a page and you can compare these with the folderstucture and contents.
If many pages need to be checked you can copy all url's with Ctrl-All , Ctrl-C and Ctrl-V it in an editor that is capable of sorting and removing duplicates so that you have a nice list of files being used a,nd can do your folder cleanup in one move.
Related
Well in general I am new to BizTalk and maintaining a very old setup, BT 2013 R2
Overall I am well versed in .XSLT and feel more comfortable managing xml directly than I do in the BT IDE ( well the vstudio IDE)
So here are a couple generic architecture questions:
What are the steps to manage the maps manually through notepad? I see a lot of code in the .BTM.CS file, but those don't seem to get picked up. I seem to have to change the .BTM file first, then it generates the .BTM.CS
My Map is Huge, I'm working with X12 and there are thousands of fields, what can I do to make this easier? I have to scroll through 10 layers deep just to make anything visible, then expand the map. BT IDE seems to have a big issue dealing with such big files
Also any books anyone can recommend on the subject would be appreciated
I will say this first, I totally understand where you're coming from, but...
You don't, sorry. The BizTalk Visual Studio Project System is an integral part of BizTalk development and you really, really, really should not even try using a text editor. .odx, .btm, .btp are all meta files managed by their respective designers. The .cs files are generated at Build-time so there is not opportunity to modify them at all.
One way to improve Mapper performance is to areas of function into separate Tabs. The rendering of the design surface is the problem so the less to render at once, the better. Even separating direct links and Functoids helps.
Sandro's book is the current standard: BizTalk Mapping Patterns & Best Practices
Johns-305's answer is good - I'd just add that with XSLT in maps you do have the option of setting "Custom XSLT" for the map in the properties window. That can then be pointed to an external (source controlled) XSLT file which you could then edit using any XML/XSLT editor (Visual Studio or not). Just be aware that this option means you won't be able to us any of the visual mapper functionality, and the .btm file will basically just be a pointer to the compiler to use your custom XSLT rather than the XSLT that would be generated by BizTalk. You should not try to manage BizTalk's generated XSLT in this manner - only for cases where you're certain you want to use custom XSLT rather than the visual designer. To do that, open the map in Visual Studio (1), click the grid area (2), and then set the Custom XSLT Path (3):
(It's possible to do that by directly editing the .btm file, but not recommended - I did write a blog a little while back documenting the .btm format for what it's worth though: https://blog.tallan.com/2015/03/26/biztalk-mapper-file-format-btm-documented/.)
For orchestrations, you're out of luck.
It may look silly to ask this question but tricky for me to know the technical reason behind, so you might share with me the actual reason ;)
Why when using Visual Studio I check out a single file of all files related to an aspx page (.aspx, .aspx.vb, aspx.designer.vb) then in my pending changes I see all the files are checked out!?
for example I just do small change e.g. an attribute in login.aspx then in pending changes will see login.aspx.vb and login.aspx.designer.vb are checked out and when compare them with previous version NO CHANGE can be found in them?
To put it simply, in Visual Studio multiple files can represent a single 'resource' such as a form or a web page. Some of these files are generated automatically by the IDE, and generally contain code which isn't intended to be edited manually.
For example, in a WinForms project, the form.vb file will contain all of the methods you're used to seeing, and writing code in, while the form.Designer.vb file has IDE generated code that declares and positions the various controls that have been placed on the form in the designer.
These two files represent code for the same resource (a form), but are kept separate to keep inexperienced programmers from making detrimental changes [easily], and to keep your user generated code cleaner. Naturally, though, since they are merely pieces of a whole, editing one affects the other.
For a detailed list of file types in Visual Studio, have a look here.
If you are using TFS as your Source Control... Check what settings you have for Source Control... I'm still using 2010 as I still have to develop in XP. In Team --> Team Project Settings --> Source Control you will see some options. In the Check-Out Settings tab I have the Enable Multiple Checkout option checked and Enable Get Latest On Check-Out is unchecked. This has allowed me to checkout single 'resources' at a time. As mentioned above certain files are grouped and editing one will check-out the group.
We're investigating if it's possible to have the following: A webpage with multiple 'folders' to which a user can drag & drop a files. It's meant to be used as an interface to upload scanned documents to an archive.
For example, we would have page that states: 'Quotes', 'Invoices' & 'Misc'. Depending on the sort of document the user would drag & drop the file from the local file system to one of these three folders. It should then upload the file to the correct folder on the web server.
Is this possible, and if it is, any existing solutions using ASP.NET?
You can use modern browsers HTML5 functionalities to do so. A detailed explanation here:
http://www.useragentman.com/blog/2010/01/10/cross-browser-html5-drag-and-drop/
There is also the jQuery plugin: https://github.com/weixiyen/jquery-filedrop This one is a bit bogus (truncates files with accents like in french, doesn't handle correctly several drop areas in the same page, ...), but are easy to fix (I sent a fixed version to the author weeks ago, but didn't get any feedback...)
With some Ajax and the correct server-side solution, it works like a charm. I don't know any .NET solution, though.
Best,
You could use a silverlight app or a java applet, but those are the only solutions that I know of... The users would obviously need to have silverlight or the jre installed.
We are working on an ASP.NET CMS project using jQuery as the basis for our client side scripting.
The jquery-1.2.6.js file is the only script file that is always included. Other script files are currently included depending on what components the CMS editor is using on a page or page template.
A lot of the script combiners produce a static script. If we took that approach we would have to add all possible script files in just in case they were needed. We are not currently using any of the ASP.NET Ajax extensions so have not looked at what that may give us.
Anyone got any suggestions?
I have read Combining and Caching multiple JavaScript files in ASP.net but I don't think that covers off the conditional nature of our situation
So great I can use ScriptManagerProxies and some methods on the base master Page. However there is one other thing. Stopping all the ASP.NEt Ajax guff being sent down to the client. I am going to take a look at bleroy's hack until ASP.NEt 4.0 releases
TIA
Pat Long
Working in Sitecore on a site that had multiple scripts for different pages, we created a list of script items in Sitecore, then added a Multlilist field to the Items. We had a placeholder in the head of the master page, and dynamically added the scripts as they appeared in the multilist field. We did the same thing with CSS as well. It worked out nicely. (Specifically, it was on http://www.utulsa.edu)
Edit: I misunderstood what you originally meant. It seems like you may need combine and produce all the possible static scripts you need, then dynamically include the one you are looking for, if you're looking for only one script include per page.
Otherwise, you could just depend on caching to keep your script requests down, and do what you are currently doing
Edit 2: A third thought is you could write your own combiner that will combine scripts on demand, and include the generated (or pre-generated) script
I don't know if this will help you or not, but Scott Hanselman posted on twitter that you could download issues of MSDN Magazine for free. I followed the link and looked through a couple of issues and this month (Feb, 2010), and one of the first articles discusses predictive fetching with jQuery and ASP.NET Ajax.
This looks like it could be along the lines of what you're looking for. As far as stopping the AJAX requests, I haven't read the entire article, but I'd assume it mentions something in there (as predictive fetch would have to account for this).
One thing that's really been making life difficult in getting up to speed on the codebase on an ASP classic project is that the include file situation is kind of a mess. I sometimes find the function I was looking for being included in an include file that is totally unrelated. Does anyone have any advice on how to refactor this such that one can more easily tell where a function is if they need to find it?
EDIT: One thing I forgot to ask: does vbscript have any kind of mechanism for preventing a file from being included twice? Sorta like #ifndef's from C?
There are a few basic things you can do when taking over a classic ASP application, but you will probably end up regretting doing them.
Eliminate duplicate include files. Every classic ASP app I've ever seen has had 5 "login.asp" pages and 7 "datepicker.js" files and so forth. Hunt down and remove all the duplicates, and then change references in the rest of the app as necessary. Be careful to do a diff check on each file as you remove it - often the duplicated files have slight differences because the original author copied it and then changed just the copy. This is a great thing for Evolution, but not so much for code.
Create a rational folder structure and move all the files into it. This one is obvious, but it's the one you will most regret doing. Whether the links in the application are relative or absolute, you'll have to change most of them.
Combine all of your include files into one big file. You can then re-order all the functions logically and break them up into separate, sensibly-named files. You'll then have to go through the app page by page and figure out what the include statements on each page need to be (or stick with the one file, and just include it on every page - I can't remember whether or not that's a good idea in ASP). I can't comprehend the pain level involved here, and that's assuming that the existing include files don't make heavy use of same-named globals.
I wouldn't do any of this. To paraphrase Steve Yegge (I think), "there's nothing wrong with a classic ASP application that can't be fixed with a total rewrite". I'm very serious about this - I don't think there's a bigger waste of a programmer's time in this world than maintaining an ASP app, and the problem just gets worse as ASP gets more and more out of date.
#MusiGenisis bullet point list is good advice to follow but I'd disagree with -
"I wouldn't do any of this. To paraphrase Steve Yegge (I think), "there's nothing wrong with a classic ASP application that can't be fixed with a total rewrite". I'm very serious about this - I don't think there's a bigger waste of a programmer's time in this world than maintaining an ASP app, and the problem just gets worse as ASP gets more and more out of date."
All very well, but if it's a sizable legacy app doing complete re-writes is often not possible due to a lack of developer time/resource.
We have a fairly large classic ASP app which has grown arms and legs over the years, it's not pretty but it does serve the business needs. We have no time to spend the next six months doing a complete re-write, it would be nice, but just not possible. Our approach is -
Where there's new functionality required, it's implemented in ASP.NET. This happens 95% of the time. The 5% edge cases usually being that there are a large number of points where the new app code touches the old app requiring us to do a lot of classic ASP re-work potentially making the app more fragile.
Where there's a change in functionality we assess whether we can refactor to ASP.NET with minimal impact. If this isn't possible then we'll implement the change in classic ASP and tidy up existing code as we go along e.g. simplifying include file nesting, replacing javascript with more cross browser friendly code, that kinda thing.
In answer to your question about #ifndef's, there isn't an equivalent I'm afraid.
Use one file to global headings and includes (lets name it t-head.asp). This file is included in all asp files.
Use one file to make the site visual global header (logos, menus, etc) and include it right behind . Let call it t-begin.asp
Use one file to make the site visual global footer (copyright, google analytics, etc.) and closing all divs or tables opened in t-begin.asp. Lets call this file t-end.asp
Use one folder to put the business logic files, called BUS. The files in this folder can not have includes. Every function inside the file must be preceded by the name of the logic unit (IE: all function in products.asp must begin with product_*)
Use one folder to put some reused UI code called UI. The files in this folder can not have includes.
Example:
<%# Language=VBScript %>
<% Option Explicit %>
<% Response.Buffer = true%>
<html>
<head>
<!--#include file="../general/t-head.asp"-->
<!--#include file="../bus/product.asp"-->
<title>Products page</title>
</head>
<body>
<!--#include file="../general/t-begin.asp"-->
<% 'all your code %>
<!--#include file="../general/t-end.asp"-->
</body>
</html>
Wow. It constantly surprises me how many people have a hate for ASP. In decent hands it's a perfectly capable language for designing web applications.
However, I will concede that the way include files are managed in ASP can be a bit of a brainache -- because (depending on how you use them) they have to be loaded and parsed even if you're not using half the functions contained within.
I tend to have one include file (initialise.asp or some such) that itself includes links to several functions libraries (lib_http.asp, lib_mssql.asp or similar) and all library functions are self-contained so there is no worry about crossing variables. Any global vars are declared and set in the master file. This means I can use a function anywhere, any time and not worry about where it was defined, it's just there for use. And IDEs such as Visual Studio and Primalscript have the ability to "jump to definition" when you find a call to a function that you don't recognise.
Then, any script-specific includes are included in the script after the call to this master include file.
I concede that this is a memory-hungry approach as all the functions in all the libraries are compiled for every script call, so the method needs refining for each site you develop -- decide what to call via the master include and what is more page-specific. It would be nice to be able to only load what you need -- but that's the DLL approach and is not available for the majority of real-world developments, and also you'd have to weigh up the processor cost of compiling small scripts vs loading components.
A concise directory structure is requisite and easily developed, but it can be a chore to wade through all the code in an existing site and change any links or mappath calls. Also, be aware that some IIS administrators disallow the '..\' method of traversing directories via VBScript, so then all file references have to be absolute paths.
i think you should consider moving your code from ASP VBScript to Visual Basic COM DLLs. that'll ease on you having too much includes.
I don't know of a way to prevent a double inclusion, other than getting an error message that is. Are you seeing includes placed throughout the page, which is making them difficult to spot?
Just as an aside, are you working with a copy of the code and the database on a development server? From my experience, the first thing to do is separate yourself from the live site ASAP. While a hassle initially, it'll give you the freedom to make changes without messing up the live site. It's easy to make that one tiny change in an include and BAM! the whole site goes down.
I've worked through a few projects like you've described and used the following strategies:
Complete rewrite - perfect when there's time/money, but usually I get the call when something has gone wrong and results are needed ASAP.
Smaller projects - I open up everything in the IDE and just start searching all the project files for the functions/sub, in order to build a knowledge of the include logic. Pretty much each time, everything is spread out everywhere, so I start rebuilding the includes organized by business logic. I've also run across inline code (raw code, not subs or functions) thrown into an include, so I'll usually just pull the code back into the page for refactoring later.
Larger projects - I'll use some code I have laying around to parse the includes for lines with sub/function headers and dump those to a text file to build up a list of what routines are where and refer to that. This comes in handy when you've got a ton of includes on each page and can't get your head around the codebase.