I suddenly started getting the following error in the "General" ouput window of Visual Studio 2010 when loading the database project as part of a pretty large solution:
Cannot evaluate the item metadata "%(FullPath)". The item metadata "%(FullPath)" cannot be applied to the path "obj\Debug|Any CPU\Database.dbschema". Illegal characters in path. C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets
Nothing has changed in the .Net framework recently, and there is not mention of FullPath in the Database.dbproj file.
Googling around yielded this blog entry, but resetting the Visual Studio environment did not help:
http://social.msdn.microsoft.com/Forums/en/vstsdb/thread/14eecc38-87fe-4234-b5fa-c2fa7cab9ae9
After much banging my head against the wall, it occurred to me to try and load the DB project on its own, outside the solution. Lo and behold, that worked. This gave me the clue that something was wrong with the solution itself. I compared the .sln file that was generated when I opened the project on its own with the contents of the large solution, but nothing obvious jumped out. In the end, I deleted the .suo file and that solved it for about a day. The next day, the problem returned, and deleting the .suo file did not fix it.
The culprit? ReSharper 6 EAP. Disable ReSharper and the problem goes away.
http://youtrack.jetbrains.net/issue/RSRP-255109
As a side note for someone that may stumble on this post in the future. Whenever you get a error that says something like:
cannot evaluate the item metadata (fullpath) etc...
Most of the time this relates to the character limitations of paths that cannot exceed 260 characters all the way to the bin folder. It is a really cryptic error that has wasted too many people's time in the past.
Watch the length of those project names and the depth of your folder structure ;-)
Related
I am currently working on a build of a Solution with several Database Projects (Staging, Core, Business) in Visual Studio 2013. Unfortunately I get into troubles, when i have the same object in different projects.
Error: SQL71508: The model already has an element that has the same name DIM.
As there are build dependencies, the first project will be able to CREATE the schema DIM. The second one will fail. Therefore a lot of errors will be thrown.
How am i able to solve this issue?
It was very confusing, but what finally solved my issue was:
saving & closing the solution
removing all *.dbmdl files (each project had one)
reopening the solution
Reopening took a while, but finally those errors were gone.
Function of DBMDL files
Today I came across a bug that I'd like to share with everyone.
When trying to execute an SSIS package in Visual Studio (2015 and 2017 the following can happen (note this package was executed sucessfully before).
While on the bottom it clearly says the SSIS package is finished, the data flow task is still in progress (and will never finish). What also happens (don't know if consistently) a CMD window pops open with "SQLDUMPER.EXE".
This is not due to the way the steps are configured, since executing them individually might still lead to the proper results.
Note as well that in my case this problem makes Visual Studio incredibly unstable. It is not uncommon that after or during every execution Visual Studio crashes completely and is automatically shut down by Windows.
There are no error messages and I had no idea what the reason is this happened untill... (answer below)
After a lot of googling i've found a reason whya multitude of people seem to have this problem.
Right click the project and then click on properties
Click "Debugging"
Set "Run64BitRunTime" to "True"
Apparently for most people this fixes the problem.
For me however I had to come up with another solution.
Right click the project and click on properties
Click "General"
Set "TargetServerVersion" to either the target SQL server and run the package again OR set it to any SQL server version, run the package to see if it works, and if it doesn't set it to another version.
These solutions are counter intuitive because this problem seems to arrise at a random moment and the target sql server version might have been the same throughout the entire development.
I have not tried to see what happens when I deploy the bugged project to a server and see if it runs there, so any and all extra information on this problem would be appreciated.
I spent a good bit of time googling this problem. It looks like it is being reported by many people around the world. It is usually down to either x32/x64 compatibility or some miniscule issue with sorting or data sizes or compiling a custom C# script (or combination thereof).
None of these things worked for me so I rebuilt the entire package from scratch and the issue was gone.
It is far from perfect, especially if your package is large and/or complex but if nothing else works, this is your last resort.
"Run64BitRunTime" was already set to "True", but I was getting this error. so I restarted the visual studio and problem resolved.
None of the proposed solutions worked for me. I had to rebuild both the solution and the project a couple of times and this fixed it. Of course, I opened and closed the VS a couple of times in between. I guess this is a bug and you have to tinker with it to get it to work.
I'm running into a small but weird annoyance that seems to be happening to other people, too (for example, check out the revision history of SEDE). I have a SQL Server 2008 database project in Visual Studio 2010 that works properly. When I go to commit/checkin to source control, I'm told that my DB project's .dbmdl file has changed, even when I've made no changes to the project!
I'm not sure if the changes are triggered by building my solution (which also includes an ASP.NET MVC application and a unit test project) or by simply opening the DB project, but this is getting kind of annoying and is creating clutter in source control.
Is it possible to stop these changes from occurring, or get rid of the .dbmdl file whatsoever?
If you delete the .dbml file, it is rebuilt without errors or warnings, so I think it's just a cache file for references, intellisense, etc. I'm going to exclude it from source control.
I believe Visual Studio serializes the dbmdl file every time the project is opened. The only possible work around would be to keep the project open.
See related question here. The .dbmdl file is unique per user (and some kind of cache, as said above) and so the right solution is indeed to exclude it from source control.
Bear with a bit me before jumping straight to the normal caching fix solutions. Here's what happening:
I have a project, a single project out of dozens in our solution that appears to be refusing to update its code when I build and run. It's not part of the xap, but a dll sitting along side the xap.
Things I've already determined not a solution:
I've checked the output of its dll and it has been built, and its contents updated to match my code, verified with dotPeek. But it refuses to display the updated code.
I clean, rebuild the solution, and restart the dev server but it refuses to display the updated code.
I switch to a different browser, no dice.
I clear browser cache's to no avail.
I completely delete my local code and do a fresh fetch from our repository, again, no love from silverlight.
I have not been without a little success though. The ONE bone I've been thrown was over the weekend. Not touching it for a couple days, I came back to work on Monday and, without having done anything to it, it just updated. Now, however, it's cached again, or something, because it's stuck in the last set of changes I made to it.
So my question is this: What am I missing?
Most likely your files may be read only and MS Build fails to display error message and it does not update files. In case if you have mistakenly checked in your .xap files, then this is possible, you will have to remove it from your source control and also make .xap file writable by removing readonly checkbox.
Visual Studio checks in your .xap files by mistake and silverlight build does not report any error.
Second, do you have any other file backup service installed like Shadow copy or Dropbox kind of online backup service, something is probably making xap files readonly and that is causing this problem.
Here there are couple answers: Prevent Silverlight 3 from caching while debugging
Code below helped me(add this to Page_Load of page that hosted the app ):
Response.Cache.SetExpires(DateTime.Now.AddSeconds(-100));
Response.Cache.SetCacheability(HttpCacheability.NoCache);
UPDATE:
Prevent Silverlight xap from being cached by proxy server
"So my question is this: What am I missing?"
An internal caching mechanism that our application uses. So, none of you could really have helped me as it was an architectural feature of our software.
I'm running into a small but weird annoyance that seems to be happening to other people, too (for example, check out the revision history of SEDE). I have a SQL Server 2008 database project in Visual Studio 2010 that works properly. When I go to commit/checkin to source control, I'm told that my DB project's .dbmdl file has changed, even when I've made no changes to the project!
I'm not sure if the changes are triggered by building my solution (which also includes an ASP.NET MVC application and a unit test project) or by simply opening the DB project, but this is getting kind of annoying and is creating clutter in source control.
Is it possible to stop these changes from occurring, or get rid of the .dbmdl file whatsoever?
If you delete the .dbml file, it is rebuilt without errors or warnings, so I think it's just a cache file for references, intellisense, etc. I'm going to exclude it from source control.
I believe Visual Studio serializes the dbmdl file every time the project is opened. The only possible work around would be to keep the project open.
See related question here. The .dbmdl file is unique per user (and some kind of cache, as said above) and so the right solution is indeed to exclude it from source control.