I need to know the exact MS Project version of the file that is uploaded in my system. In the MPXJ library, the ProjectProperties class exposes two apis - getApplicationVersion() and getMppFileType() but they both return an Integer. Which number is mapped to which version is not clearly mentioned. The mpxj documentation explains that the getMppFileType returns 12 for MS Project 2003 and 2007 and 14 for 2010 and 2013. But how to distinguish between the both ? Is there a single straight-forward api that can give this info ?
Unfortunately it doesn't appear that the exact version of Microsoft Project used to create a file is embedded in the file itself. At the moment the closest you can get is to look at the application version attribute, i.e. you want to use the ProjectProperties.getApplicationVersion() method. Here's the list of possible values it will return:
Project 98: 8
Project 2000: 9
Project 2002: 9
Project 2003: 9
Project 2007: 12
Project 2010: 14
Project 2013: 15
Project 2016: 16
Project 2019: 16
Related
How do I get programatically current Windows 10 UAP version?
I did not find any suitable class or method.
GetVersionEx does not seem to be supported.
For things like metrics and analytics, you can use the new AnalyticsInfo class. The version number you get is a string-ized representation of the four-part version number (major.minor.revision.build).
My application has minSdk at 15 and targetSdk at 20. I need a support library because my application uses the PageViewer view.
Reading the documentation I read that the support library vx is designed to be used on the API level x. I think that the version's number x should be between 15 and 20.
How should I choose that number?
Secondly, using android studio I have to add the following line in a file named build.grandle, for using the support library v4.
compile 'com.android.support:support-v4:20.0.0'
What is the meaning of the suffix 20.0.0?
The support libraries have different revisions/versions. You can check more info here
Adding this part in your gradle file:
compile 'com.android.support:support-v4:20.0.0'
you are telling gradle to get the support-library-v4 with revision 20.0.0.
About which version you should use. If you compiling with api20, you can use the revision 20.
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 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! :-)