I am facing VS crash problem after copying SSRS report design.
I need to modify SalesInvoice SSRS report. Our normal practice is to make a copy of the design we are going to modify before starting modification.
Before i copy the design (design_1), i do rebuild to SalesInvoice, the rebuild can be success with two warmings.
Successful Compile Msg:
After duplicated a design by copying and pasting it, i tried to rebuild the copied design, i got following error message.
Compile Error Msg:
I remove the copied design (design_1) and try to copy other design (design_2). design_2 can be rebuilt successfully.
I tried to duplicate other designs, only some of them has rebuild error.
I believe that it should be some error in those designs.
is there any way i can easily locate what and where the problem is in those report designs?
My environment is AX 2012 R3 CU11 (6.3.4000.127) with VS 2013 version update 5 (12.0.40629.00) and SQL 2012 64-bit (11.0.6567.0).
We upgraded AX from R2 to R3 this year and the report has no such issue before.
By reducing obsolete report design, the problem can be fixed. Too many designs will cause report size too big and it will lead VS becomes unstable when compiling.
Related
I have encountered a bizarre situation in which.....
a Win32 project (originally compiled/run using Visual Studio 2010) has been successfully carried over/updated and successfully compiled under Visual Studio 2015 on the same computer (mentioned just in case that is somehow relevant).
I now need to continue development of the project on a different computer. So I copy the ENTIRE contents of the project folder to an identically named folder on the new computer, with VS 2015 installed. The only difference being that the project folder is now on the D: drive rather than C: as in the original computer.
When I try to compile the program I get:-
fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt
I experienced this error in the past with Visual Studio 2010 and fixed the problem as advised in previous articles such as:
Failure during conversion to COFF: file invalid or corrupt
In this case however the puzzle is that, as mentioned above, the project has already successfully compiled on the computer it was copied from AND the new computer appears to have a correct and up to date VS2015 installation (e.g. the issue cannot be due to incorrect version of the CVTRES.EXE file - as was case when the same error was encountered in the past with Visual Studio 2010)
As far as I can tell the configuration settings for both VS2015 installations, on both computers are the same. The only difference as far as I can tell being that on the new computer the project now resides in a different drive/path - although the project folder is indentically named.
Can this really be the source of the problem?
The problem has now been, apparently, solved. I tried the /verbose option but that did not reveal any information or insight of any use.
The computer on which the project had been transferred to had Visual Studio 2010 WITHOUT service pack 1 installed. As an entirely separate exercise I proceeded to install service pack 1 (from a previously saved/archived ISO file). It failed to install. I then uninstalled VS 2010 from the computer.
I then tried again to compile my project using VS2015 - and again it failed, giving the error 1123.
I then performed a FULL re-installation of VS2010. I followed this with an another attempt to install the service pack 1 - which then succeeded.
After all this I then attempted to compile my project in VS2015 - and it succeeded! The connection with the VS2010 may be completely coincidental? But I mention this here for the record in case anyone else encounters a similar circumstance.
The puzzle is how, if at all, can the state of the VS2010 installation influence the ability to compile the project in VS2015. The concern, more importantly, is that my continued ability to work on/compile the project using VS2015 will be dependent on the computer keeping VS2010 w/SP1 installed?!
I have an SSDT project where I recently changed from SQL 2008 to SQL 2012. I re-exported my references DACPAC files using the SQL 2012 SqlPackage and replaced the SQL 2008 DACPACs with the new 2012 versions. Now I am getting unresolved reference errors for all of the referenced databases.
Strangely enough, IntelliSense auto complete works with the objects in the DACPACs. I can get all tables and columns to auto-complete and show their datatypes, even on the object SSDT is complaining about.
Is there a know issue with SSDT when migrating versions? I have another project using these DACPACs and it builds without error.
I would do three things, the first is double check that each dacpac is at 2012 - when I had a mixed project it was a nightmare, mixing versions causes all sorts of issues with references.
Secondly, open each of the dacpacs as a project in Visual studio and make sure that each of them build correctly, it might be a reference from one of those to something in master etc that is causing subsequent build failures.
Finally do a clean of the solution and build just the dacpac project, look for any messages or warnings in the output window, the answer will be there but just hard to see.
ed
Visual Studio sometimes decides to rebuild my entire huge project because of one small change. I turned build logging up to Diagnostic to see what was the problem, and here's what I'm seeing:
< Bunch of spam >
Outputs for C:\<snip>\PRECOMPILEDHEADERS.CPP:
C:\<snip>\PRECOMPILEDHEADERS.OBJ
All outputs are up-to-date.
Forcing rebuild of all source files due to a change in the command line
... and then it rebuilds my precompiled headers, then everything else.
This happens when I change a single .cpp or .h file inside the project. I'm not changing anything in the project settings. It also doesn't happen all the time for the same change; it's random.
Any ideas on what's going on here? Where can I get more information? I tried enabling debugging via the description in http://blogs.msdn.com/b/vsproject/archive/2009/07/21/enable-c-project-system-logging.aspx but it didn't give any more information. I can't figure out where this "Forcing rebuild of all source files due to a change in the command line" is coming from. It's not in any of the factory MSBuild files.
Some other info: it's a C++/CLI dll project that links a lot of other projects, including C#, native c++, and other C++/CLI dll's. I tried removing all the C# projects from the dependencies since those tend to cause problems, but that didn't change it. I've googled that specific string, but my situation doesn't match that of any of the other people reporting it. (One was using Intel C++, another was MSBuild from the command line and changing the case. I'm hitting build solution from within Visual Studio itself).
Edit to explain common fixes I've tried:
I've tried building only the project. Does the same thing.
I'm not including any .h files that don't exist.
I've deleted the bin/object folders and rebuilt from scratch. This usually makes it go away for a couple builds, but then it comes right back.
Edit #2:
Found something suspicious earlier in the log:
3>Using "ResolveNonMSBuildProjectOutput" task from assembly "Microsoft.Build.Tasks.v4.0, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
3>Task "ResolveNonMSBuildProjectOutput"
3> Resolving project reference "..\..\..\..\CommonCore\VS2010\Project1\Project1.vcxproj".
3> Project reference "..\..\..\..\CommonCore\VS2010\Project1\Project1.vcxproj" has not been resolved.
This is repeated for several of my projects... I'm gonna chase that down and see if maybe it's a problem with the project reference hint paths.
Ok, it's an old thread, but I encountered the same problem recently.
My solution was to disable the precompiled headers - now a simple change in one sourcefile won't lead into a "rebuild" any more.
I have had the same problem with Visual Studio 2012 recently. I'm on Windows 7 with Visual Studio 2012 Professional (2012.2) building C++ projects. It's worth noting that I recently migrated the solution from Visual Studio 2008 to Visual Studio 2012.
One of the C++ projects (an executable with a DLL project as a reference) was rebuilding every time one of its compilation units was changed, e.g. simply saving main.cpp would cause all compilation units (including the pre-compiled header) to rebuild. I spotted the the following message in the build logs:
Forcing rebuild of all source files due to a change in the command line since the last build.
I turned build log file verbosity to Diagnostic (Tools > Options > Projects and Solutions > Build and Run) and compared the log files from a clean build and a build after one compilation unit has been changed (which forced a full rebuild). I noticed that:
"Path" had changed from one build to the next (";C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\Extensions\Microsoft\VsGraphics" seems to have been tacked on the end)
there was a difference in TaskTracker.exe command lines to do with CancelEvents
there was a warning about OutputPath not being set
I pulled my hair out.
I eventually resorted to recreating the offending project from scratch rather than relying on the project that was automatically generated during the migration process from 2008 to 2012. It seems to be behaving as expected now.
I did three things, and the problem seems to have gone away. I'm trying to narrow it down a little but I figured I'd go ahead and post them:
Deleted and re-added all the references and project references
Fixed one of my projects that wasn't setting the .NET framework target to 3.5 to match the rest of my solution (I was getting away with it because the project didn't use .NET anyway)
Set "Copy Local Satellite Assemblies" to false for all references including System ones.
Beware that some or all of this stuff might be voodoo...
I have one OPC ( OLE for Process control ) server project which is developed into visual studio 2005. I want to run it in visual studio 2008. The coding for the OPC server project is done in VC++. I want to connect my OPC client to this OPC server. When I was opened the OPC server project which was build into visual studio 2005 into visual studio 2008 first time it was asking for conversion wizard. I gone through that wizard & successfully finished that wizard. But when I build ( by right clicking on the project & choosing build solution ) it is giving lots of error near about 64 errors. Most of the errors are like - fetal error C1083:Can not open type library file:'msxml4.dll':No such file or directory, fetal error LINK1181:can not open input file 'rpcndr.lib' , error C2051:case expression not constant. only these 3 types of errors in am getting. All these 3 errors are repeated in Error list & becoming bunch of 64 errors. Please provide me the solution for the above issue. Can you provide me any suusgestion or link or any way through whcih I can resolve the above issue?
In Visual Studio Project go to Project properties dialog to use Linker --> Input Options:
1. Remove rpcndr.lib
2. Make sure for all such configurations add rpcrt4.lib
Reason to do this is that the Windows SDK no longer ships with rpcndr.lib.
Opening in VS 2008 is the only way to upgrade.
But it looks like you need to clean up some of the references... this will be a manual step (likely just need to set a few paths). Start by fixing the first error, it is likely many of the subsequent errors are a consequence of that first error.
Normal practice is to have a copy of referenced libraries (including typelibs) somewhere in your source tree, so you are not dependent on absolute paths into the OS or other application's install folders. (Or the continuing existence of that library).
I had been happily coding along on a decent sized solution (just over 13k LOC, 5 projects) which utilizes Linq to Sql for it's data access. All of sudden I performed a normal build and I received a sweet, sweet ambiguous message:
Error 1 Build failed due to validation errors in C:\xxx\xxx.dbml. Open the file and resolve the issues in the Error List, then try rebuilding the project. C:\xxx\xxx.dbml
I had not touched my data access layer for weeks and no adjustments had been made to the DBML file. I tried plenty of foolhardy tricks like re-creating the layout file, making copies and re-adding the existing files back to the project after restarting Visual Studio (in case of some file-level corruption); all to no avail.
I forgot to wear my Visual Studio Skills +5 talismans, so I began searching around and the only answer that I found which made sense was to reset my packages because Visual Studio was not loading an assembly correctly. After running "devenv.exe /resetskippkgs" I was, in fact, able to add the dbml file back to the DAL project and rebuild the solution.
I’m glad it’s fixed, but I would rather also gain a deeper understand from this experience. Does anyone know how or why this happens in Visual Studio 2008?
New Edit: 10/30/2008
THIS WAS NOT SOMETHING THAT JUST HAPPENED TO ME.
Rich Strahl recently wrote on his "web log" about the same experience. He links to another blog with the same issue and used the same action.
I have encountered this issue a few times since this original post as well, making me think that this is not some random issue. If anyone finds the definitive answer please post.
After installing Phalanger for Visual Studio 2008, I attempted to create a new PHP WinForms Application. The project creation failed with a similar error message, stating that a DLL required could not be loaded (Failed to load file or assembly...). Running the devenv.exe /resetskippkgs command in Visual Studio 2008 Command Promtp resolved the issue immediately.
Thanks for the info.
I also get this error when trying to compile the data access layer in the second solution (installer). What I do is that I run Custom Tool on the dbml-file, and this does it.
There is really no errors in the dbml file that needs to be corrected.
My theory in this is that Visual Studio caches the compiled version of the dbml file, and that the cache is invalid for other solutions. I guess running /resetskippkgs does the same thing as recompiling the dbml file.
Anyway, there are no fix for this yet?
TBH, I have had a couple of instances like this where files "seemed to go crazy".. However, upon investigation it has appeared that the files have changed in some way, shape or form.. (e.g. sometimes changes can be made to the file by inadvertantly changing a property somewhere that seems unrelated).
I think there are too many possible issues that could really cause this, and based on the fact that the problem has been resovled, it seems like an answer will not be found..
I had the same issue in VS 2010 (build failed due to validation errors in dbml file). I resolved this by viewing the designer view of the dbml file and dragging a table slightly to a different location so that it refreshed the dbml layout etc files. This seemed to do the trick, but was a bit of a weird issue.