I have a sample solution that has a different "test" icon on one of the test projects, but not on the other two.
I thought that maybe the project type guid was different on this project, but in the solution file they all have the same project type (C#)
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "DomainModel.Tests", "DomainModel.Tests\DomainModel.Tests.csproj", "{61A4733D-4C5B-4705-98CB-8048751BBEFA}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Extensions.Tests", "Extensions.Tests\Extensions.Tests.csproj", "{1D6AA1C5-1FEC-44E4-9258-ACF84A20353C}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Repository.Tests", "Repository.Tests\Repository.Tests.csproj", "{248434B7-3690-4705-85F0-66B765AEB431}"
EndProject
And in each project file they have idential project types (Test and C#)
<ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
Why does DomainModel.Tests have the correct test icon, but Extensions.Tests and Repository.Tests have a plain C# library icon?
This can also happen in VS2013 when starting with a class library project and then adding test classes from there.
Adding the following child node to the main PropertyGroup node in the project file fixes the icon in this case:
<ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
This is fixed in the Visual Studio 2013 preview.
This problem isn't fixed in VS2012 Update 2 (VS2012.2).
I would expect that it will be fixed in the next version of Visual Studio if it isn't fixed in a quarterly update before then. With all of Microsoft moving to shorter release cycles (approximately 12 monthly) then we shouldn't have that long to wait; at least not compared to how long we've had to wait in the past! :-)
Related
As suggested in this post, If I install the VC++ redistributables for VS2015 update 3 am I likely to break other software running on the same PC built with previous updates to VS2015? Similarly, if I stick with update 2 for my release, is this going to get broken at some point in the future when someone installs the redists for update 3?
Based on the bug description as reported at New VC Runtime 14.0.24210.0 breaks MFC app built with VS 2015 Update 2 the U3 redistributables will indeed break MFC apps compiled with U2 or earlier, which:
use MFC in a DLL i.e. not statically linked, and
create objects of type CMFCToolBarButton or derived.
From the linked page:
The problem is caused by the new BOOL member m_bIsDragged in class CMFCToolBarButton.
So memory layout differs between Update 2 and 3.
When initializing m_bIsDragged in the constructor, the (stack) memory behind the ToolBarButton is overwritten.
The problem should arise also on all classes which are derived from CMFCToolBarButton:
CMFCColorMenuButton
CMFCCustomizeMenuButton
CMFCDropDownToolbarButton
CMFCOutlookBarPaneButton
CMFCRibbonGalleryMenuButton
CMFCToolBarComboBoxButton
CMFCToolBarDateTimeCtrl
CMFCToolBarEditBoxButton
CMFCToolBarFontComboBox
CMFCToolBarFontSizeComboBox
CMFCToolBarMenuButton
CMFCToolBarMenuButtonsButton
CMFCToolBarSpinEditBoxButton
CMFCToolBarSystemMenuButton
[ EDIT ] For completeness, it should be pointed out that apps that use AppLocal deployment of the MFC/CRT DLLs are not affected, since they do not use the system-wide installed copies thereof.
AppLocal deployment is described under bullet #6 "updated September 11 2015" in "Distributing Software that uses the Universal CRT" at Introducing the Universal CRT.
I've inherited a legacy .Net 3.5 VB app to support from a client and they'd like to make some small data changes. Before we begin I think it's important to note that I am running Windows 7 64 bit, and VS 2013 Ultimate R2.
While making my first changes to the project, I noticed their datasets use a custom tool AGDataSetGenerator (written by Shawn Wildermuth in 2004). I did a lot of poking around on how to register custom tools. I went over to http://www.codeproject.com/Articles/8582/Inherit-from-ADO-NET-DataSet-to-create-your-own-bu and got the source code of the tool, inside the project there are a couple of utility files that you need to run in order to register the tool. Remember this was made in 2004 so things were a little different back then.
I modified the Reg.cmd file to point to v2.0.50727 since my project is running .Net 3.5 and .Net 3.0 and 3.5 are both just minor updates from .Net 2.0 and not completely new .net versions. Also I noticed that there is both a Framework and a Framework64 folder with the C:\Windows\Microsoft.Net folder, so I added both locations to my .cmd file in hopes to cover all of my bases. Code Below
Reg.cmd - Original
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\regasm /codebase /verbose F:\AGDataSetGenerator.dll`
Reg.cmd - My Modified Version
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\regasm /codebase /verbose F:\AGDataSetGenerator.dll
C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\regasm /codebase /verbose F:\AGDataSetGenerator.dll
Then it was on to the.reg file.
Upon opening the file my first thought was, cool, I can just switch the version from 7.1 to 12.0 and away we go. Not the case. After quite a bit of googling I found the first line registers the tool for VB.Net, and the second registry entry registers the tool for C#, so for me I only need the first line, also VS now a days registers to a new location HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\VisualStudio\ for 64 bit specific registers. So in hopes to cover my bases once again, I tried including both 32 bit and 64 bit locations. I even threw in a more global register for both 32 and 64 bit that in hopes that would point visual studio to the generator entry, unfortunately I'm a bit out of my wheelhouse here so I was pretty much grabbing at straws.
BSDataSetGenerators.reg - Original
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.1\Generators\{164B10B9-B200-11D0-8C61-00A0C91E29D5}\AGDataSetGenerator]
#="ADOGuy DataSet Generator"
"CLSID"="{87BF1B1C-E1DF-4f24-A07E-2BD9B8CAD316}"
"GeneratesDesignTimeSource"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.1\Generators\{FAE04EC1-301F-11d3-BF4B-00C04F79EFBC}\AGDataSetGenerator]
#="ADOGuy DataSet Generator"
"CLSID"="{3C13044D-394D-45cd-89FF-51C885BFBCD9}"
"GeneratesDesignTimeSource"=dword:00000001
BSDataSetGenerators.reg - My Modified Version
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\12.0\CLSID\{87BF1B1C-E1DF-4f24-A07E-2BD9B8CAD316}]
#="AGDataSetGenerator"
"InprocServer32"="C:\\WINDOWS\\system32\\mscoree.dll"
"Class"="BottomLine.Generators.VBNETAGDataSetGenerator"
"Assembly"="AGDataSetGenerator, Version=1.0.0.0, Culture=neutral, PublicKeyToken=35e4ca7ea38d2508"
"ThreadingModel"="Both"
[HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\VisualStudio\12.0\CLSID\{87BF1B1C-E1DF-4f24-A07E-2BD9B8CAD316}]
#="AGDataSetGenerator"
"InprocServer32"="C:\\WINDOWS\\system32\\mscoree.dll"
"Class"="BottomLine.Generators.VBNETAGDataSetGenerator"
"Assembly"="AGDataSetGenerator, Version=1.0.0.0, Culture=neutral, PublicKeyToken=35e4ca7ea38d2508"
"ThreadingModel"="Both"
[HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\12.0\Generators\{164B10B9-B200-11D0-8C61-00A0C91E29D5}\AGDataSetGenerator]
#="AGDataSetGenerator"
"CLSID"="{87BF1B1C-E1DF-4f24-A07E-2BD9B8CAD316}"
"GeneratesDesignTimeSource"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\12.0\Generators\{164B10B9-B200-11D0-8C61-00A0C91E29D5}\AGDataSetGenerator]
#="AGDataSetGenerator"
"CLSID"="{87BF1B1C-E1DF-4f24-A07E-2BD9B8CAD316}"
"GeneratesDesignTimeSource"=dword:00000001
Regardless of everything I've tried. When I right-click a dataset and try to run custom tool. BAM! I get the following:
If anyone can get this working in similar settings to my own, I'd love to know how you did it.
I'm very much the type of person that find's it very hard to take NO for an answer when it comes to technology. Unfortunately the answer here is simply just "No". The custom tool is very much outdated and to get it to work in VS 2013 just isn't feasible (I still can't bring myself to say impossible).
I'm writing this answer because I have a workaround that I suggest anyone in the same situation use straight out of the gate instead of trying to get that old tool to work. As a workaround, I created a new data project in .Net 3.5 and used entity framework to bring in just the models I needed to update. I generated my models from database and then went to the .aspx code behinds and replaced references to the outdated generated datasets. It took some refactoring but using EF instead of those ancient generated datasets cut the code by about 40%. Win Win in my opinion. Hope this helps someone else in the future.
According to the old .reg reference to VS 7.1, that means it was built to work in VS 2003. I know that VS plugin coding changed a lot in VS 2010 and later editions. So, it is possible this plugin may only work in VS 2003... possibly all the way up to VS 2008. But, it may need to be re-written to work in anything later.
Hopefully you have MSDN or know someone who does. I would spin up a VM, install VS 2003 (or you could try up to VS 2008), and install this plugin using the original .reg/.cmd.
I am trying to reference a single project from two different projects in VS 2012. Example: both 1 and 2 are referencing 3. This despite not being a circular dependency, is still not working for me. Project 1 gives the error "The type or namespace could not be found", whereas project 2 can successfully reference project 3. I need this kind of setup because of my architecture and can't reference 1 and 2 directly.
As example, that third project is class library. You should be able to reference it from project1 and project2. Maybe close visual studio, clean, rebuild it and also check if project1 or project2 is not referencing each other. Try to delete those references and add again: class library reference to project1 and then to project2.
Changing the .Net framework for project 1 from Version-4 to Version-4.5 did the trick for me.
This is the answer to my question. stackoverflow.com/a/6090384/1099142
I just found that cocos2d-x 3.0 beta has defined own macro "$(EngineRoot)" under vs2012 proj, I want to know how to do it!
I can not upload the img...
Assuming you generate a cocos2d project using the cocos.py script as recommended in the docs, you'll find that EngineRoot is defined in the project's cocos2d_headers.props file near the top as follows:
<PropertyGroup Label="UserMacros">
<EngineRoot>$(MSBuildThisFileDirectory)..\..\</EngineRoot>
</PropertyGroup>
You should be able to do the same in your own (non-generated) project.
I am using Portable Class Libraries (PCL) in Xamarin Studio on OS X. I have two PCL libraries that are targeting .NET 4.5, Windows Phone 8, Windows Store Apps, Xamarin.iOS, and Xamarin.Android. I reference these two libraries in my iOS, Android, and Unit tests projects. In 3 areas I am getting the following error:
The type 'System.Object' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
The code is straightforward:
MyClass myClass = new MyClass();
The error occurs once in each of the projects that reference the PCLs. None of them are the same class. I am new to PCLs. I've tried removing the Windows Phone 8 (as I added it last minute) and yet the problem does not go away. Any help would be appeciated!
Thanks!
Update:
So this occurs with the first field declared in the class (where the class is from the PCL project).
int a = 0;
MyPCLClass _myPCLClass = new MyPCLClass(); //This is where the error appears
Another odd aspect is that there are over 50 classes using these classes, and the error is only appearing in three classes.
I just ran into this exact same problem, and have the same setup as you do. A tip mentioned in a comment (by Stuart, which in turn mentioned a tweet by #DavKean) to this question solved it for me.
You have to:
access a Windows machine (I used a Windows 8)
grab C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\Facades\System.Runtime.dll
copy it to your Mac
add a reference to this dll from each of your iOS and Droid projects
Which version of Xamarin.Android and Xamarin.iOS are you using? You need to be using of the Xamarin.Android 4.7.x alphas for PCL support, or the forthcoming 4.8 release. (Ditto for Xamarin.iOS: you need a pending future release for PCL support, or use the alpha channel.)