I inherited a Gatling project originally built against v3.2.1, and understand that version 3.3.1 has been released since the project was last actively maintained, so I updated that in the build.sbt file, and started getting "wrong checksum" errors on the command line (e.g. wrong checksum: C:\temp\SSCCE\null\Coursier\cache\v1\https\repo1.maven.org\maven2\org\scala-sbt\sbt\1.3.2\sbt-1.3.2.pom (expected SHA-1 4f8a5d7e2bf4c184d43ae9cc18466e23878ca5db in C:\temp\SSCCE\null\Coursier\cache\v1\https\repo1.maven.org\maven2\org\scala-sbt\sbt\1.3.2\.sbt-1.3.2.pom__sha1, got edf765410c981897fdce97c5629bbc0342509b43))
I found discussion of using Ivy vs Coursier, so included the lines below
useCoursier := false
update / checksums := Nil
This still didn't help, so after a little more searching, I cleared the project/null/Coursier/cache folder & retried. This allowed me to build & run the tests, but all requests threw the exception j.n.s.SSLException: failure when writing TLS control frames, and I can now reliably switch between building & getting the exception if I use Coursier, or building & getting no exception if I use Ivy. The project folder is not small, but I put together a SSCCE.org project to demonstrate this behaviour should anyone please have time to offer thoughts.
Related
It has been answered before, but i don't know the way to find the exact solution. I took whole day to find the solution but i entirely stuck with this.
I was worked with my project nicely on day before yesterday. I designed many modules for doing my project further. AS usual i opened and started doing (I didn't get any errors) my project today in visual studio. To execute my old project(coding) once again, i checked in browser, as soon as i did, my face gone too bad :( because of this strange error. Error is,
Compilation Error
Description : An error occurred during the compilation of a resource required to service this request. Please review the following specific error details and modify your source code appropriately.
*Compiler Error Message:*CS0009: Metadata file 'c:\Windows\Microsoft.NET\assembly\GAC_32\System.EnterpriseServices\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.EnterpriseServices.dll' could not be opened -- 'Error importing module 'System.EnterpriseServices.Wrapper.dll' of assembly 'c:\Windows\Microsoft.NET\assembly\GAC_32\System.EnterpriseServices\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.EnterpriseServices.dll' -- An attempt was made to load a program with an incorrect format. '
Source Error:
[No relevant source lines]
I did deleting temporary files in this area : C:\Users\username\AppData\Local\Temp\Temporary ASP.NET Files. But again I'm getting the root folder when am running the project
Any help, would be more and more helpful to me. Thanks in advance.
The error message
An attempt was made to load a program with an incorrect format
means that there is an incompatibility in processor architecture. I think you installed either the 32- or 64-bit version of .NET and try to run your website in the opposite architecture.
You should install both the .NET framework versions, or change your application pool to use the right processor architecture.
A lot of time can pass between the moment a stack trace is generated and the moment the stack trace is thoroughly investigated. During that time, a lot can happen to the file in question, sometimes obscuring the original error. The error might have been fixed in the meantime (overlapping bugs).
Is it possible to get Stacktraces that show the offending file at the time of the error?
Not elegantly, and you normally don't want the user browsing through code that's throwing unexpected exceptions anyway (open door to an attacker).
Usually, what happens in a dev shop is that the user reports an error, stack trace, and the build it occurred on. As a tester, you can grab that build from your archives (you ARE keeping an archive of all supported releases somewhere handy, RIGHT?), install, run, and try to reproduce the error, working with the user to provide additional info as necessary. I've seen very few bugs that couldn't be reproduced EVENTUALLY, even if it required running the program against a backup of the user's production database to do it.
As a developer, you can download that build's source code from your version control repository (you ARE using version control, RIGHT?), and examine the lines in the stack trace to try to discover the problem by inspection, and/or build and run it to reproduce the error. Then, you go back to the latest source version, build, and run the same steps (a UI automation system can help out here), and if you don't get the error, someone else already found and fixed it. If you still get the error, you also got an updated stack trace with lines that match the current build, allowing you to set your breakpoints and step through.
What KeithS said, plus there are ways to capture more helpful state information at the time of the Exception using the Exception.Data property. See http://blog.abodit.com/2010/03/using-exception-data-to-add-additional-information-to-an-exception/
While KeithS' answer as pretty much correct, it can be easier and more elegant than you think. If you can collect a dumpfile (instead of just a stack trace), you can use a Symbol Server and Source Server in combination with your debugger to automatically pull your correct-version code from source control.
For example: if you enable PDB output and source-server integration in MSBuild, and upload the resulting PDBs to a symbol server, Visual Studio can automatically load the correct source control from a TFS or SourceSafe repository based on the information in a minidump.
Whats the advantage of pre-compiling an ASP.NET project using aspnet_compiler.exe?
Also, is there a possibility that a the compiled project will have errors after it is being deployed to a remote server? There is an issue raised by the team that maybe if the machine where the project is compiled and the server where the project will be deployed will have different settings, the project will not run or run erroneously. Has anybody encountered this situation?
I see two principle reasons:
Compile time error checking.
Avoiding overhead of compile on first page fit.
The first of these allows more errors to be detected while in development (e.g. typo in property name) rather than getting the yellow screen of death. If the code in question is an error path, it can be hard to ensure test coverage so things can slip through.
This cannot guarantee that there will be no errors in production. Clearly logic errors will not be found at compile time, nor will missing error handling (to name but two huge categories of bugs).
Also it will not prevent missing reference problems due to a missing assembly (present on the development machine but not deployed to production). Thus good practice is still to have a staging environment (this could also be for acceptance testing) which is treated by developers and testers as if it were production --- only access is to deploy a corrected version (no direct fixing) so fixes all start in development (and source control).
Another advantage is protecting your source code if you have to deploy to an untrusted environment (e.g. shared hosting), as you only deploy binaries which make it much harder for a third party to do any reverse-engineering than if you have all your .cs files up there.
You won't see any cross-platform issues just from performing the compilation. Check out this answer which explains how .NET runs on different architectures.
Why do server errors occur on running a solution, even if the solution is building successfully?
Compile time versus run-time errors. See this stackoverflow thread for the difference between these two.
From wikipedia:
Thus, for example, a "run-time error" is detected only during the execution of the program, whereas a "compile-time error" is detected by the compiler before the program is started.
It's impossible for the compiler to catch all errors beforehand: see the 'halting problem'.
There are several possibilities:
Difference in run-time vs. compile-time environments (version of .NET, version of IIS, system-level web.config or machine.config or applicationHost.config, etc)
Run-time errors vs. compile-time errors
Different security environment / permissions
Different database connection string requirements
Using IIS vs. Cassini
If you have dynamic references (eg. if you're using NHibernate, for example), it's possible that there are references to an assembly that's not present. These kind of references cannot be picked up by the compiler. It's only one of many possible situations where you'll get a run-time error that's not logic related.
As Q8-coder said, what is the error? Impossible to give solutions without knowing what the error is.
I am running mxmlc in the command-line with -incremental=true. Flex is building the cache file using a checksum the first time. Subsequent compilations fail with this message:
Failed to match the compile target with path_to_cache/projectname_329043.cache. The cache file will not be reused.
path_to_cache exists
the cache file exists in path_to_cache
the compiler is not trying to create a new cache file, so I assume it is generating the same checksum
My environment:
Flex 3.0
Mac - OSX 10.4.x
I just ran across this issue myself and after not finding the answer anywhere on the web, I bashed my head against mxmlc in practically trail-and-error until finding the answer. In my case, I was regenerating the flex config xml file each time I compiled from within ant. It turns out that this is the error you get in the case where it thinks the config has changed. You can test this by simply touching your config file and running against unmodified sources. So, if the timestamp is changing on your flex config.xml between compiles, that is likely the culprit.
It could be a permissions issue. Have you tried running with sudo? I wouldn't recommend doing that permanently, but if using sudo makes the error message go away, then you know it's a permissions issue; and you can move on to the proper way to resolve it.
You could also try going into Disk Utility and doing a check/repair of disk permissions. OSX has been notorious for needing this done occasionally.