This may be a stupid question and/or a futile effort -- you've been warned...
I have a ASP .NET application (with the VB parts compiled to a DLL). This application has been around a while and the person who wrote it apparently messed up the old source code repository system. He is no longer around and I'm not clear on whether the source code I was given was a re-write or an older version (or by some strange luck the actual version of the website running).
Being that part of this website is running as a DLL, what is the best way I can go about in determining if the version of the source code I have matches what is running? I'm unable to setup an IIS server to throw this on (licensing/server cost/time/etc).
Is there a better way than compiling the project and then finding some disassembler and doing a comparison?
Is there a better way than compiling the project and then finding some disassembler and doing a comparison?
That's what I've done in the past in your situation.
Open each compiled assembly using ILSpy, and use the option "File / Save Code" to generate source files.
Build the source code from your source code repository, and use ILSpy to generate source files.
Compare the results of 1 and 2.
Obviously this won't give you the whole picture - you'll also need to compare aspx files, config files, ..., but it's the only approach I know.
Related
Denizens of Stack Overflow, I come before you in hopes of solutions to my current problem, as so many of my questions have been answered by you veritable founts of knowledge. Is there a simple way to create a unit test for an ASP Web Site Project that was already created without requiring the installation of software that requires you to buy them should you wish to continue using them? If there was a way to get the ASP Web Site directory to be treated as a Project, that would solve things very smoothly. There are two methods to accomplish this that might still be viable but that I have given up on are:
Linking the ASP Website Project to a normal Visual Studio Project.
A method I saw online suggested that one could simply drag the ASP.Net Web Site Folder on to a normal VS Project and this would effectively make the Project a copy of the ASP Web Site with all functionality of the Web Site for Unit Testing with the sublime easiness of being able to use Add Reference for the Unit Test Project, so much more simple than what I've encountered with Add Service/Web Reference. On a similar note, there was a website that suggested adding all the content of the ASP Web Site into the Root of a project. Neither of them worked for me, but I might have been made a mistake in my interpretation of the instructions.
Once I gave up trying to get the Unit Test to Add Reference to the ASP Web Site, my next approach was to link a Web Reference to the Unit Test. At first I tried placing the http://localhost(number)/ of the ASP Web Site in the Web Reference URL, but that didn't work. I saw something that mentioned creating an IIS Site for the Unit Test to reference, but I couldn't make much sense of it.
I've been trying to come up with a wsdl file, and to that end I downloaded WCF LOB Adapter 2013. I don't have BizTalk installed, and after the software provided the message that BizTalk needed for BAM to be installed, I decided against downloading further software. BizTalk itself was already about 660 Megabytes, and for something that is easily a fifth the size of the entire Windows 10 Operating System, I thought that BizTalk ought to be able to run without needing additional specialized software.
I recently discovered that .asmx pages happen to show up when I tried to Add a Web Reference. Instead of giving me an error about connectivity, I received an error stemming from how I had duplicate web.config files in the same solution thanks to trying so many different approaches without success and not clearing them out.
I haven't really looked much into MVCs because the tutorials I go through don't really show how you use MVCs to test the existing code of one of the various aspx pages that my company wants to have Unit Tested.
I think I was having success with [this][2] tutorial, but trying to run a asmx file I created gave me the "Not well formed" error, and my Command Prompt doesn't recognize me as administrator, even though Control Panel says I have admin privileges, which seems to be a large impediment to applying the different work-arounds. However, after using "Clean Solution" several times and deleting other projects from the solution, I was able to run the asmx file after all. However, now I'm stuck on the end of the 2nd step where a batch file (.bat) is supposed to be creating a .cs file in the Bin folder from the .asmx page.
I've gotten to where the Visual Studio Developer Command Prompt is okay with both 'wsdl' and 'wsdl.exe' no longer give the:
wsdl/wsdl.exe "is not recognized as an internal or external command, operable program, or batch file" error.
The contents of my batch file are:
wsdl /l:CS /n:WService /out:bin/wsdlWalkthrough.cs
http://localhost/webserv.asmx?wsdl
Since I'm trying to follow the steps of an article old enough to have graduated elementary school, the syntax may easily have changed. Instead, now I get the error:
'http:' is not recognized as an internal or external command, operable
program, or batch file.
I'm going to make this one into a question in and of itself, because this question was if there was a smooth, simple, cost-free way of setting up a Unit Test for an ASP.Net Web Site, not specifically to answer any of my problems, though such would be received with much gratitude.
[Another tutorial][3] might yet provide me a solution, but I'm not going to hold my breath.
UPDATE 2/29/2016
With assistance from Stack Overflow's ever so helpful ChristiFati, I was able to get through Dimitrios Markatos' Creating and Consuming .NET Web Services in 5 Easy Steps which can be found at http://www.sitepoint.com/net-web-services-5-steps-3/ The article may be over a decade old, but it was still by far the easiest method I came across in my week or two of trying to figure out a way to add a reference, or in this case Add Web Reference that I came across. Two things to be careful of though. The first is that if you copy and paste code directly from the tutorial, you might end up with errors because the batch files you make will have an extra newline character, which caused the Developer Command Prompt for VS2012 I was using to run the .bat file to give me the
'http:' is not recognized as an internal or external command, operable
program, or batch file.
error. Thanks again to ChristiFati for pointing that out for me. Similarly, the instructions for Step 3 give you the following code for a second .bat file:
csc /t:library /out:binGetSuppliers.dll binGetSuppliers.cs
/reference:System.dll,System.Data.dll,System.Web.dll, System.Web.Services.dll,System.XML.dll /optimize
Besides eliminating the white-space and newline characters, the above code should probably look more along the lines of:
csc /t:library /out:bin/GetSuppliers.dll bin\GetSuppliers.cs
/reference:System.dll,System.Data.dll,System.Web.dll, System.Web.Services.dll,System.XML.dll /optimize
But aside from that, the tutorial was a gift from God after all the dead ends I had come across. I'm judging my question answered because the critical issue was being able to give my Unit Test a Reference, whether a normal reference or Web Reference. I do not anticipate any more major difficulties and hopefully I will be able to finally proceed to Unit Testing for one of our ASP Web Sites. If not, this post will be edited to describe the newest problem.
Well, this is ridiculous. I'm able to add the Web Reference just fine, but doing so seems to have done diddly-squat for being able to reference the different .cs pages anywhere inside the ASP.NET Web Site. Does anyone have a way to get a Unit Test to be able to reference code/classes within an ASP.NET Web Site?
UPDATE 3/8/2016
There is a somewhat simple solution to the problem in placing all the functionality of your website into a DLL. Once that is done, right-click on the Unit Test project and select Add Reference. The DLL didn't show up on any of the tabs, but I was able to select the appropriate DLL by clicking on Browse.
Still, if there's any other ways to set up Unit Tests from an existing ASP Web Site where such a DLL doesn't exist.
My Visual Studio 2013 Solution
[2]: http: //www.sitepoint.com/net-web-services-5-steps- 2/
[3]: https: //msdn.microsoft.com/en-us/library/ms731835%28v=vs.100%29. aspx
I have an ASP.NET website where the pages call a few components in DLLs. I need to change the signature of a method in the component, and short of doing a text search, don't know if this will break any pages or not. IMO, this is the weakness of web programming -- you don't get the benefit of a compiler telling you about syntax errors.
But it doesn't need to be so. Does anyone know if there is a way to run a spider over a website watching for compile errors, or perhaps some tool that would compile all the .aspx files in a folder structure looking for compile errors?
This is merely for syntax checking -- not to actually pre-compile the website.
EDIT It looks like aspnet_compiler is being recommended. I don't use Visual Studio projects for the website -- it's grown over time with my own templating system (back before Master Pages were available). So something that would run aspnet_compiler over all the files in a folder might work...
There is a flag that you can put on your project that tells it to compile all the aspx files when the project is compiled. It adds time to your build, but it can sometimes be worthwhile. See http://mikehadlow.blogspot.com/2008/05/compiling-aspx-templates-using.html
Also, Resharper is really good at finding references to methods, even in aspx files. So if you use Resharper to rename a method, as long as your solution includes the web project, it'll find and rename that method in the aspx files, too.
This is one of the many reasons we use development tools like Visual Studio in the first place. The single easiest way to do what you're asking is to develop with an IDE that DOES compile and check for errors, even ifyou choose to publish teh un-compiled code.
Since Microsoft offers Visual Web Developer for free, there's really no reason to NOT use it.
The compiler will automatically catch and any report any errors in your .cs source or code-behind pages. Your assumption that the compiler won't catch syntax errors (such as getting the arguments in the wrong order when calling a method, etc) is incorrect - that's one of the primary benefits of using a compiled language. If you're experiencing something that contradicts this, please post some code.
If you're concerned about errors in the ASPX files or in your views (if using MVC), you can have the IDE precompile ASPX files, as well.
See this article for more information.
I turn this off most of the time since it slows down compilation, but I use it before deploying a site as an extra verification step.
I'm using the N2 CMS system for ASP.NET. Well I say 'using', I'm really just trying to develop a tiny understanding of it.
One of the things that's obstructing me is that it's set up in a way I've not seen before. Where are the codebehind files for the pages?
Can anyone tell me for example, where is the code for /Edit/default.aspx? How on earth do I debug what it is doing?
Thanks
David
It always used to be in N2.Edit.dll, but by the look of it they've rearranged this in more recent builds - I'm not 100% if it's now in N2.Management.dll or in N2.dll itself.
As usual the easist thing to do is to get hold of the source code (or an SVN checkout of the correct version), build it yourself and then replace the DLLs you were using with your built versions and their PDBs - you can then step into these correctly. You might want to go back to the regular releases for deployment, though.
If it's still Edit/default.aspx for you then I guess you're on the 1.5 code or thereabouts? In that case N2.Edit is built from src/wwwroot in the source code. You can just drop the entire src/wwwroot/Edit directory into place in your app and run it from the codebehind files there, not a compiled N2.Edit - that's easier to tweak, although I think it was easier to step through using a built DLL.
You may have to hunt around the build tree for all of the DLLs - I don't think they all get copied into one place. I used to take the DLLs from the N2.Edit.Tests project bin directory, and N2.Extensions and N2.Security from the N2.Extensions.Tests bin directory.
A member of my project team needs to add source code comments to many of his ASP.NET projects to provide better documentation. Some members of the project team recommend that we conduct thorough regression testing if we add any source code comments since there is a remote chance that some of the source code might inadvertently get commented out and cause a change in behavior of the program. We would also then be required to put the application through a management of change procedure and redeploy to our production server.
It seems to me that we should be able to add the the source code comments, recompile the source code, and use something like an md5 (or sha1) hash (using something like fciv) to compare the before and after DLLs to confirm that the source code comments did not impact the compiled version. Testing this concept with a simple console application, I see that the problem is that the hash of the binaries will change if the version of the DLL increments. If I could remove the manifest from the binaries, perhaps I could then conduct an apples to apples comparison of the binaries.
As an additional challenge, these ASP.NET applications use the ASP.NET website compilation model where the code is compiled dynamically (presumably into %SystemRoot%\Microsoft.NET\Framework\version\Temporary ASP.NET Files folder) the first time the site is visited rather than the web application model where all of the project code is compiled into a single assembly in a bin folder.
Any ideas?
hashing of assemblies doesn't work even if the version is made constant, after each compilation a unique guid embedded inside the assembly changes, this creates a different hash each time. Is it possible to change the application so that it is pre compiled?
There is a tool called bitdiffer that will compare assemblies and report any difference. As part of your integration testing you could run the tool against your new build and compare it to the build in production. this would ensure that only assemblies with code changes get released.
There is also a tool called ndepends that has an api for comparing assemblies. It's very cool!
Rohan West's answer (thanks Rohan!) led me to the bitdiffer comments which provided the following solution:
Before adding code comments, re-create the code files from IL using Reflector and the Reflector.FileDisassembler add-in. This will generate a directory of source code files that contains the core source code only without comments.
Add code comments.
Create a second directory of generated source code files using Reflector and the Reflector.FileDisassembler add-in.
Use a differencing tool such as WinMerge to compare the before and after generated source code directories and confirm that the source code comment changes did not change the core code.
In all of my other .net apps my build process (a mixture of nant and custom tasks) automatically updates the [AssemblyVersionAttribute] AssemblyInfo.cs with the current build number before the call to msbuild, stamping in the build number in the version number.
I'm now working on my first BizTalk project and I'd like to do the same thing with the version numbers of the BizTalk assemblies, but I've run into trouble!
First of all the aseembly version numbers are stored in the btproj files, so I did some googling and found www.codeplex.com/biztalk which looked like the answer to my problem, but there is a deeper problem!
I have a project for my schemas and another for my pipelines, the pipelines project references my schemas project as I have a flat file dis/assemblers. The problem comes when I update the version numbers, as updating them even from within visual studio does not update the pipeline components references to the schemas.
So if I update all the version numbers manually in the VS IDE from 1.0.0.0 to 1.1.0.0, the build fails as the pipeline components flat file dis/assemblers still reference the old 1.0.0.0 version of the schemas! They don't automatically update!
Is this really a manual process of updating the version numbers of the BizTalk projects in the property pages, then building the projects and manually updating the references to them in the properties of all the pipeline components that reference them?
This means that I can't have my build process control the build number part of my version numbers!
Or is there a better method of managing the version numbers of the BizTalk assemblies?
I'm sorry to disappoint you but I've been down the exact some road I had to give up. I guess it could be possible to achieve it but it would require a lot of changes to both the binding files and other XML files (as you mentioned and even more if you have published services etc).
Maybe it could be possible to wrap all these necessary changes in a build step (a MSBuild step or similar in other build frameworks) - that would be useful!
Developer- :)
We had the similar problem and we ended up developing a small utility which would change the version number in all the projects i.e. *.csproj (asssemblyinfo.cs), *.btproj accordingly. Apart from this it would open and modify the *.btp files with the new version of schemas. In nutshell, what all you have to do is to configure this utility in your VS.net tools menu and execute it.
I guess its not very difficult to develop such utility in any .net lanagauge.
Caveat: Do not forget to save the files after updates with the same encoding as they were originally.
Cheers!
Gutted, thought that might be the case. Maybe BizTalk 2009 projects will play more nicely when updating references when changing version numbers.
I started to go through and automate it manually, and when I realised what needed to be done, I took a biiig step back when I realised just how many places I'd have to modify to get it working. Thank god for Undo Checkout.
I do have a standard C# class library included in my project (various helper functions), which i am able to update the version number of during my build process, so I'm basically using that one assembly to version the whole application. If anyone wants to know what version is in any environment, check out the version number of that one assembly.
Not ideal, but it's working.
We've done this successfully on our project - I'll see if I can get the developer of the tool to post details...
This problem arises when you perform an integration build to the latest versions of your dependent components as file references (aka schemas here).
Keep in mind that upgrading the assemblyversion must always performed manually, that way you are always in charge of changes to assemblyversions.
A possible solution to solve the buildbreaks issue is to file reference to a specific version of a dependent component build and not to the latest version and use a subst drive and a copy script to get the latest component builds.
For example:
SchemaA, assembly version 1.0.0.0
PipelineA (with pipelinecomponent XMLValidator for example), assembly version 1.0.0.0
PipelineA has a file reference to a subst drive(say R drive, which maps to a workspace D:\MyComponents) and version 1.0.0.0 of SchemaA as follows:
R:\SchemaA\1.0.0.0\SchemaA.dll.
The copy-script copies the buildoutput of SchemaA locally to your R drive.
When schema A updates to version 1.1.0.0 you don't have any issues because you still use version 1.0.0.0 and YOU have the choice to use the 1.1.0.0 version of your schema. When you want to upgrade, you have to alter your copy-script and replace the file reference to R:\SchemaA\1.1.0.0\SchemaA.dll.