Since Visual Studio 2017 version 15.8 we have on some computers in my team the following really weird build error.
Additionally Visual Studio recognizes it
but the IDE itself doesn't crash.
To check if it only happens to our own solutions I created a new simple, plain command line tool project which shows the same build behavior. So it isn't exclusive to our solutions.
I tried to get help from Microsoft but it seems they don't know what to do about it. The thread doesn't show all the material I provided to them. They got a lot of logs and a sample project from me. A crash dump wasn't possible to provide, because Visual Studio itself doesn't crash.
Repair and full uninstall, new install of Visual Studio didn't help either.
Edit: It is not only occurring on my development machine but on our build servers (there are two of them), too. Interestingly our VMs on the development machines does not seem to have this issue.
To me it seems, the problem has something to do with loading assembly from GAC, so I would suggest to try reinstalling Microsoft.CodeAnalysis assembly and see if it helps.
To Do that:
Install Microsoft.CodeAnalysis package to your project with it's required dependencies, make sure to note down all assemblies being downloaded.
Run Visual Studio Developer Command prompt as an Admin
Uninstall existing assemblies from GAC by using command gacutil /u [name of assembly] (do this for all assemblies from step 1)
Install newly downloaded dll using command gacutil /u [Path to Dll] for all dlls (do this for all assemblies from step 1)
Remove package from your project
I hope this helps!
Unfortunately in this case you have only three two options:
You could try to describe all the steps to reproduce this crash so much detailed as you could with a lot of screenshot images from this steps. Use for this DOC file format, PDF or some like that. This file you have to send to Visual Studio support.
You could try to create the crash dump. Each time Visual Studio crashes, it will create a dump file devenv.exe.[number].dmp file in the configured location. Each dump file produced by this method will be up to 4 GB. in size. Make sure to set DumpFolder to a location with adequate drive space or adjust the DumpCount appropriately. I know, you wrote already on MS forum that this error doesn't create one dump. But would you like to imagine that you have 10 crashes on a day and on each crash one dump file in size 4 GB. will be written? The dump creating is disabled normaly and you have to enable it. How to enable it you could find using search string in Google: "How to enable dump files in Windows" or for Windows 10 you could see this video. Alternatively or additionally you could use the programm tool "ADPlus" for creating memory dump files and log files with debug output from one or more processes. This tool is very detailed describen on this MS Support page.
You could try to debug by yourself. But in the case if you want do it you have to see "Tools listing Included in Debugging Tools for Windows".
Normaly by Visual Studio support do not work the Visual Studio developers. You have to be nice to them and they do what they can do. You could not expect from them that they all know. They do their job using some given instructions.
In your case the support worker has gived you the link Reporting Visual Studio crashes and performance issues in which you have to read the following part:
Directly reproducible crashes
Directly reproducible crashes are cases which have all of the
following characteristics:
Can be observed by following a known set of steps
Can be observed on multiple computers (if available)
If the steps involve opening a project or document, can be reproduced in sample code or a project which can be linked to or
provided as part of the feedback
For these issues, follow the steps in "How to Report a Problem"
and be sure to include:
The steps to reproduce the problem
A standalone repro project as described above. If this is not possible, then please include:
The language of the open projects (C#, C++, etc.)
The kind of project (Console Application, ASP.NET, etc.)
Any extensions that are installed.
Most valuable feedback: For this case, the most valuable feedback is the set of steps to reproduce the issue along with sample source
code.
Unknown crashes
If you're not sure what's causing your crashes or they seem random,
then you can capture dumps locally each time Visual Studio crashes and
attach those to separate feedback items. To save dumps locally when
Visual Studio crashes, set the following registry entries:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\devenv.exe]
"DumpFolder"="C:\\Crashdumps"
"DumpCount"=dword:00000005
"DumpType"=dword:00000002
⚠️ Each dump file produced by this method will be up to 4 GB. in size. Make sure to set DumpFolder to a location with adequate
drive space or adjust the DumpCount appropriately.
Each time Visual Studio crashes, it will create a dump file
devenv.exe.[number].dmp file in the configured location.
Then, use Visual Studio's "Report a Problem..." feature. It will
allow you to attach the appropriate dump.
Locate the dump file for the crash you are reporting (look for a file with the correct Creation time)
If possible, zip the file (*.zip) to reduce its size before submitting feedback
Follow the steps in "How to Report a Problem", and attach the heap dump to a new feedback item.
⚠️ Do not attach heap dumps to existing feedback items. Please create a new feedback item for each heap dump you would like to
submit. If you were requested to provide a heap dump in order to
resolve a previous feedback item, simply reply to the request with a
link to the new feedback item where the heap dump is attached.
Most valuable feedback: For this case, the most valuable feedback is the heap dump captured at the time of the crash.
Please read it very carefully and in best case two or even tree times successively.
I hope it will help you and I wish you good luck!
As suggested with Dipen in another answer problem seems to be in Microsoft.CodeAnalysis try reinstalling nuget package for that & re-register in GAC if missing.
If Issue still exists, you can try disabling code analysis on your project like:
In Project in VS 2017, open References & right click on Analyzers and click on Open Active Rule Set like:
Uncheck all rules so that no code analysis is done on your project like:
3 .Save All files and now try rebuilding & run the project to see if issue is resolved.
The issue was an older JustMock version installed. Could only solve it with the help of the Roslyn team.
I'm trying to configure Visual Studio 2012 to allow me to step into ASP.NET MVC 4.0 source code. (System.Web.Mvc.dll). I've followed SymbolSource's recommended configuration but when I try to load the symbols, Visual Studio can't locate them.
Recommended configuration
To configure Visual Studio for symbol/server
use, follow these instructions:
Go to Tools -> Options -> Debugger -> General.
Uncheck “Enable Just My Code (Managed only)”.
Uncheck “Enable .NET Framework source stepping”.
Yes, it is misleading, but if you don't, then Visual Studio will
ignore your custom server order (see further on).
Check “Enable source
server support”.
Uncheck “Require source files to exactly match the
original version”
Go to Tools -> Options -> Debugger -> Symbols.
Select a folder for the local symbol/source cache.
Add symbol servers
under “Symbol file (.pdb) locations”. Pay attention to the correct
order, because some servers may contain symbols for the same binaries:
with or without sources. We recommend the following setup:
http://referencesource.microsoft.com/symbols
http://srv.symbolsource.org/pdb/Public or the authenticated variant
(see above)
http://srv.symbolsource.org/pdb/MyGet or the authenticated
variant (see above) (other symbol servers with sources)
http://msdl.microsoft.com/download/symbols (other symbol servers
without sources)
I am aware that the source code is available on CodePlex, however I'm specifically interested in stepping into the code using a symbol server instead of having to unreference Mvc from the GAC and reference a locally built assembly.
Has anyone had success doing this with MVC 4.0?
Just add a symbol server that serves more then just major releases.
Try this one, contains most minor builds.
http://srv.symbolsource.org/pdb/Public
Verify:
Run VS as administrator.
Check that something have been downloaded to your symbol cache directory.
Goto select only specified modules.
Add "System.Web.Mvc.dll"
Set a break point in your code. Start debug.
When break point hits rightclick in callstack on any mvc.dll row. Verify that symbols are loaded.
if loaded, try dubbleclick on one callstack row to open mvc source.
Get back with where you get in trouble.
I will make some refinements to Luke Gumbley's anwser.
Microsoft tries to make a developer's life easier. Whenever it release an MVC version installer, there should also be a Source to download. So people can use the source to explore what is installed by the Installer, as well as to debug the MVC.
Back to the way of downloading the MVC debug info. Your Visual Studio (I use 2010) will never try to download MVC PDB files from the aforementioned servers if you have MVC4 installed on your system. In this case, your Visual Studio will use the MVC from your GAC when you run debugger.
I have tried the way suggested by Luke Gumbley. However, once you uninstall MVC, your MVC project will not be loaded, and you cannot create a new MVC project since the Template is gone. So please don't unistall MVC. If you do so, you still need to reinstall it. This wastes time.
What you really need to do is exit your Visual Studio, run command
gacutil /u System.Web.Mvc
Then go to C:\Windows\Microsoft.NET\assembly\GAC_MSIL, remove or rename the offending System.Web.Mvc folder. After this, lanuch your Visual Studio, and fetch the MVC package from NuGet.
I can't answer on your question directly and provide you URL with symbols (.pdb) for System.Web.Mvc.dll for ASP.NET MVC 4.0, but probably I can help you to solve the problem in another way.
As well known (see here for example) Microsoft provide the current source code of .NET on http://aspnetwebstack.codeplex.com/. In the post it's described how to use the Nightly version of ASP.NET (the current developer state of the code). If you didn't used Git before you can have problems with downloading RTM version of ASP.NET 4.5 (with ASP.NET MVC 4.0) which you could prefer to use instead of Nightly version. Nevertheless the downloading of the full source code of RTM version is easy enough. You need just to know that Git allows to save copy of the code in branches or tagged versions. In the way you can get access (and download it) to some previous versions of the full code. The link for example provide you jQuery 1.8.2 instead of another link get you the latest developer version which can be unstable. So to download the source code of RTM version you just need to choose "v2-rtm" branch and then click on "Download":
You can use the link to select "v2-rtm" branch directly.
I can repeat that it's not exactly what you asked and I know that compiling of ASP.NET source code could be also a little tricky, but I decided do write the information. If somebody would suggest you the better solution it would be interesting for me too.
I had exactly the same issue (correct version but no symbols), but after a day or so of trying everything I've been able to get it working. These are catch-all instructions that worked for me, they may contain unnecessary steps:
Sign up for SymbolSource and follow the VS instructions using the
authenticated URL form
Uninstall all versions of MVC with add/remove programs
Remove MVC assembly from the GAC (the question is about modifying
MVC but the GAC answer is good)
Remove and then reinstall the MVC 4 reference to your project with
NuGet
Start debugging, open the modules window, and cross your fingers
that ‘Symbols loaded’ is next to System.Web.MVC when it appears.
(sprinkle in restarts as you see fit, for me the key final step was reinstalling the NuGet reference)
My theory is that as the GAC library is used at runtime in preference to the local reference, the symbols are not found when they are searched for. By removing MVC from the GAC and then reinstalling the NuGet reference, it seems the local reference is used and the symbols are found. It's counterintuitive as the System.Web.MVC.dll files are binary-equivalent between NuGet and the GAC, although they are dated differently.
I'm not totally convinced though as I tried to do the same thing for Razor and that didn't work.
Let me start with that ReSharper provides a handy dialog to step in the code at any time:
So you get the following code screen if you drill to the source code:
But I became curious to accomplish this by hand. I started with proper pdb configuration:
After that I got the following error:
Next I copied the C:\Users\Andrew\AppData\Local\Temp\SymbolCache\MicrosoftPublicSymbols\System.Web.pdb\CA49C4332DE847FA967F58AFF370B70E1\System.Web.pdb to C:\Users\Andrew\AppData\Local\Temp\SymbolCache\System.Web.pdb (to match the lookup path). After that i encountered this:
And it turned out that the mismatching builds are only good for browsing the source, not debugging. (Current machine has VS2012 RC, hence MVC libraries are not RTM). If they match, you'll the the source.
I still don't know why doesn't the lookup path adjust to symbol configuration. Hope this helps.
I just solved this same problem.
The problem is that the dll stored in the GAC does not correspond exactly to the published pdbs on symbolsource.org. The one on symbolsource corresponds apparently to the latest version available through Nuget, and the one in the GAC must the one installed with .NET Framework 4.5. (.Net uses whatever is on the GAC before attemting to use anything local to your proyect, you can see this, when debuggin, go the Debug->Windows->Modules, there the System.Web.Mvc.dll is the one from GAC according to its path)
What I did was to include in the GAC the System.Web.Mvc.dll on the package folder of my solution, the one downloaded through Nuget. This you can do by using gacutil on a VS Command Prompt (run the VS Cmd as admin).
You can check on the same Modules Windows, right clicking on the System.Web.Mvc.dll, and then on Symbol Load Information. With the "old" GAC dll you get a message like (part of it)
SYMSRV: http://srv.symbolsource.org/pdb/Public/System.Web.Mvc.pdb/1E540B87149F4031B9CDEACAD8D771231/System.Web.Mvc.pdb not found
Notice here the subfolder 1E540B87149F4031B9CDEACAD8D771231 (yours might be different)
After replacing the GAC dll for the one recently downloaded through Nuget, the message is
SYMSRV: System.Web.Mvc.pdb from http://srv.symbolsource.org/pdb/Public: 336067 bytes
http://srv.symbolsource.org/pdb/Public: Symbols downloaded from symbol server.
C:\Users\\AppData\Local\Temp\SymbolCache\System.Web.Mvc.pdb\68B2330E48624B6C9DE05BED1C8C320F1\System.Web.Mvc.pdb: Symbols loaded.
Notice the subfolder 68B2330E48624B6C9DE05BED1C8C320F1, which is the one that is searched for in symbolsource.org is the correctly found.
Hope this helps
There's some related info here: http://aspnetwebstack.codeplex.com/discussions/399312
And here: Debug into nightly build of ASP.NET MVC4 using Symbolserver
I seem to have missed Day 1 of MsBuild 101. I find myself asking "What does it do, what does it replace, and when do I need it?" since I can just hit F5 and compile my application.
What is the bigger picture I'm missing?
MSBuild is the build platform that enables all build activity in the Visual Studio world.
A better, more practical example would be to state that
The .csproj files (every C# project) are msbuild files
When you hit F5, you basically (oversimplifying) call msbuild.exe and passing in your .csproj file.
MSBuild empowers all the things that make hitting F5 work. From creating the "debug" or "release" folder, to dropping references into the bin\ directory, to invoking CSC ... and everything in between ... MSBuild "powers" all that.
If all you will ever need from a build is the output that F5 gives you, then you know about all you probably need to know about MSBuild.
In most commercial/practical development scenarios, however, there will come a time where there is a need to customize the build process. The most common approach is automating the build process (using either TeamBuild or some homegrown system). You may also need to
create a "packaged" deployment
link to another library outside of your project that is also actively
being developed
publish your build to an FTP and send an email to a customer notifying
them of its availability.
The use of a unified and extensible build platform (ie MSBuild) is what makes all these these possible, while still being part of the build process ... keeping the "build" part of the development pipeline simple and contained.
It's useful when you want do automated builds, and have to implement a build process
The F5 Key Is Not a Build Process and links therein (e.g this) is a good read in that regard.
Also, your Visual Studio project files are msbuild files. If you want to do more advanced stuff when you build (e.g. run a javascript minifier, have more control over autogenerated version identifiers, post processing of files etc.) , you'll have to dig into msbuild.
msbuild is used when you want to build your project from the command line. Whenever you see a continuous integration product that will automatically build your project, it will call msbuild to perform the actual build step.
I think that build servers should have the option to press F5 key in a simpler way than via windows API.
I know this is pretty stale, but here's my take on MSBuild.
It's a scriptable build tool really similar to ANT. They both use XML for configuration, so you'll be able to figure it out fairly quickly. Both have the concept of "Targets" for instance, lots more similarities in thinking, if you know ANT the switch shouldn't be tough.
MSBuild files generated from Visual Studio is really like the generated ANT scripts you get from Eclipse that build your projects, remember your includes and define your dependencies. You can modify them directly for fun and profit.
I like MSBuild, it fixes some of the stuff I find annoying about ANT.
I currently use nant, ccnet (cruise control), svn, mbunit. I use msbuild to do my sln build just because it was simpler to shell out.
Are there any merits to switching my whole build script to MSBuild? I need to be able to run tests, watir style tests, xcopy deploy. Is this easier?
Update: Any compelling features that would cause me to shift from nant to msbuild?
I like MSBuild. One reason is that .csproj files are msbuild files, and building in VS is just like building at the command line. Another reason is the good support from TeamCity which is the CI server I've been using. If you start using MSBuild, and you want to do more custom things in your build process, get the MSBuild Community Tasks. They give you a bunch of nice extra tasks. I haven't used NAnt for several years now, and I haven't regretted it.
Also, as Ruben mentions, there are the SDC Tasks tasks on CodePlex.
For even more fun, there is the MSBuild Extension Pack on CodePlex, which includes a twitter task.
My advice is just the opposite - Avoid MSBuild like the plague. NANT is far far easier to set up your build to do automatic testing, deploy to multiple production environments, integrate with cruisecontrol for an entry environment, integrate with source control. We've gone through so much pain with TFS/MSBuild (Using TFSDeployer, custom powershell scripts, etc) to get it to do what we were able to do with NANT out of the box. Don't waste your time.
The most compelling reason to use MSBuild (at least in .NET 3.5 and beyond) - the build engine can build concurrently.
This means a huge speed up in your builds in you have multiple cores/processors.
Previous to 3.5, MSBuild didnt do parallel builds.
I feel that MSBuild and Nant are fairly comparable. If you are using one of these, I generally wouldn't switch between them unless there was a compelling feature that was missing in the product you had selected.
I personally use MSBuild for any new project, but your mileage may vary.
Hope that helps!
Edit: #ChanChan - #Jon mentions that Nant doesn't build .NET 3.5 applications. This may be enough of a reason to either change, or at least use them in parallel. As I've moved more towards MSBuild, I am probably not the most informed person to highlight any other showstoppers with either technology.
Edit: It appears Nant now builds .NET 3.5 Applications.
NAnt has been around longer, and is a considerably more mature product, and also IMO easier to use. There is a lot of community know-how out there to tap into, and it is also cross-platform, should you be interested in building apps that can run under Mono as well as .NET and Silverlight. Out of the box, it does a whole lot more than MSBuild does. Oh yes, and you can call MSBuild from NAnt (OK, from NAntContrib) :-)
On the negative side, NAnt and its sister project NAntContrib do seem to have stagnated, with the most recent update being late 2007.
The main advantages that I see of MSBuild is that it ships with the .NET Framework, so it's one less product to install; and there is more active development going on (albeit in places to catch up with the older NAnt).
Personally, I find its syntax a little more difficult to pick up, but then I'm sure continued exposure to ti would make things easier.
Conclusion? If you're working with existing NAnt scripts, stick with them, it's not worth the hassle of porting. If you're starting a new project, and you're feeling adventurous, then give MSBuild a go.
We also switched from nant to msbuild. If Your build is pretty standard, then You won't have much problems setting it up, but if You have a lot of specific build tasks, You will have to write custom ms build tasks, as there are way less custom tasks for msbuild.
If you want to display reasonable build results, You will have to mess with custom loggers etc. The whole team build is not as ripe as nant is.
But the real benefit is integration with TFS source control and reporting services. If You are not using TFS as Your source control system, it's not worth it.
Don't switch unless you have a very convincing reason (at least).
NAnt is open source and if it weren't I wouldn't be able to customize our build system, MSBuild is not.
NAnt can easily run MSBuild, I'm not sure about the other way around.
MSBuild scripts are already written for you if you use VS2005 or newer (the project files are MSBuild files.)
If you use NAnt, and you use VS to edit project files, settings and configurations, you'll have to write a converter/sync tool to update your NAnt files from the VS Project files.
#Brad Leach
I generally wouldn't switch between them unless there was a compelling feature that was missing
what are the compelling reasons to use msbuild? are there cons?
So far I'm getting a pretty good, "no don't bother" from your answer.
I think they're relatively comparable both in features and ease of use. Just from being C# based I find msbuild easier to work with than nants, though that's hardly a compelling reason to switch.
What exactly is nant not doing for you? Or are you just hoping there's some cool feature you may be missing out on? :)
One super-nice thing about C# is that if you have the .net framework, you have everything you need to run msbuild. This is fantastic when you are working on large teams / projects and have people/hardware turnover.
Personally I prefer SCons over both of them :)
The main reason I still use nAnt over msbuild for my automated builds is that I have more granular control on my builds. Due to msbuild using the csproj has it's build file, all the source in that project is compiled into one assembly. Which causes me to have a lot of projects in my solution for large projects where I am separating logic. Well with nant, I can arrange my build where I can compile what I want into multiple assemblies from one project.
I like this route, because it keeps me from having to many project files in my solution. I can have one project with folders splitting out the layers and then use nant to build each layer into it's own assembly.
However, I do use both nant and msbuild in conjunction for some build tasks, like building WPF applications. It is just a lot easier to compile a WPF application with the msbuild target within nant.
To end this and the point of my answer is that I like to use them side by side, but when I use msbuild in this configuration, it is usually for straight compiling, not performing any build automation tasks like copying files to a directory, generating the help documentation, or running my unit tests for example.
I'm actually still trying to figure this question out myself, but there is one big bonus for MSBuild here: using the same build file for local continuous integration by calling msbuild.exe directly, while also being able to use VSTS's server-side continuous integration with the same build file (albeit most likely different properties/settings).
i.e. as compared to TeamCity's support for MSBuild scripts, VSTS only supports MSBuild scripts! I've hacked around this in the past by exec'ing NAnt from MSBuild; I've seen others recommend this practice as well as the reverse, but it just seems kludgey to me, so I try not to do it if I can avoid it. So, when you're using "the full Microsoft stack" (VSTS and TFS), I'd suggest just sticking with MSBuild scripts.
Nant has more features out of the box, but MSBuild has a much better fundamental structure (item metadata rocks) which makes it much easier to build reusable MSBuild scripts.
MSBuild takes a while to understand, but once you do it's very nice.
Learning materials:
Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build
by Sayed Ibrahim Hashimi (Jan, 2009)
Deploying .NET Applications: Learning MSBuild and ClickOnce by Sayed
by Y. Hashimi (Sep, 2008)
I don't see any reason to switch. MsBuild itself locks you into the framework you are using. If you use NAnt, you can use it across many frameworks and shell out to msbuild to actually do the building task for you.
I am a fan of NAnt in this respect, because it decouples you from the framework a little bit.
I have created a framework that puts conventions into automated builds and I built it on NAnt. It's called UppercuT and it is the insanely easy to use Build Framework.
Automated Builds as easy as (1) solution name, (2) source control path, (3) company name for most projects!
http://code.google.com/p/uppercut/
Some good explanations here: UppercuT
MSBuild being integrated with Visual Studio gives programmers less friction to use the build system. It mainly comes down to them only having to go "Build Solution" and it all works, versus having to use Custom Build Steps and other such things, or, worse, forcing developers to build by launching some kind of external script.
Now, I mostly tend to prefer MSBuild over NAnt because it's simpler. Sure, NAnt has a lot more features, is more powerful, etc., but it can quickly get out of hand. If you and your build engineers have the discipline to keep the NAnt scripts simple, then it's all good. However, I've seen too many NAnt-based systems go south to a point where nobody understands what it's doing anymore, and there's no real way to debug it besides doing the equivalent of a good ol' printf. The moment you start using some if/else statement or for loop, that's where, IMHO, it starts smelling.
On the other hand, MSBuild has a solid foundation based on metadata and a less verbose syntax. Its simplicity (or lack of features... depending on how you see it) forces you to write logic in .NET code via new tasks, instead of writing logic in XML markup. This encourages re-usability and, above all things, lets you actually debug your build system in a real debugger.
The only problem with MSBuild is the not-so-occasional bug (especially in the first version) or obscure (although documented) behaviour. And, if that's the kind of thing that really bothers you, being tied to Microsoft.
I switched from NANT to MSBuild. The project is running in .Net 4.0.
My experience in Nant was good. The project kind of died. And when .Net 4.0 came along, it was time to re evaluate the build process.
Since Nant was last released MSBuild has come along ways. At this point, MSBuild is the way to go. It's easy to use, has many extensions. I rewrote my Nant scripts in a day and a half. The MSBuild script is 1/3 the size of the Nant scripts.
Much of the work in the Nant script was setting up the different environments. In MsBuild/.Net 4.0 it's built-in.
I use MSBuild alongside Nant, because the current version of Nant can't as yet compile .NET 3.5 applications (same was true when .NET 2.0 first came out).
The only reason I can see for using msbuild is if you would like to use a automated build server like cruise control. If you are not going to switch, then I would leave it alone.
I use Nant and I love it. I used MSBuild and hated it because of these:
Microsoft forces you to follow their own build procedure that is so intrinsic to their doings that I at least was not able to make it work (I had to compile NET1.1 so I had to mix Nant and MSbuild). I know you can create your own MSBuild file, but I thought it was complex to understand and maintain.
ItemTypes to do file operations are just too hard to follow. You can have Nant do the exact same things and much easier and direct (I had to create an ItemType list and then pass to the file operations).
In MsBuild you have to create your own task dll, in Nant you can do this or you can embed C# code within your script, so its much easier to advance and just build the whole project.
Nant works with Net1.1, MsBuild doesn't.
To install nant, I can even unzip and locate inside my own repository to run it. To install MsBuild is much harder since it depends on many things from Visual Studio, etc. (maybe I'm wrong here, but that seems to be the truth).
Well these are my opinions...