I am using visual studio 2010 professional edition.
I have a number of projects and solutions with the PlatformTarget set to x86 and i need to change that to AnyCPU.
It is not feasible to do it manually, since there are too many projects, so i was wondering if there is an existing macro or script that can do the conversion automatically for all projects.
If there is no such macro/script and i have to write a conversion application myself, what would be a good way to perform this conversion (simple string replace in the csproj files or is there a better way)?
Sub ChangePlatformTarget()
For Each proj As Project In DTE.Solution.Projects
Debug.WriteLine(proj.Name)
If Not proj.ConfigurationManager Is Nothing Then
ChangeProject(proj)
Else
'it's a folder, do something else with it...
End If
Next
End Sub
Sub ChangeProject(proj As Project
Dim prop As [Property] = proj.ConfigurationManager.ActiveConfiguration.Properties.Item("PlatformTarget")
prop.Value = "AnyCPU"
End Sub
Related
Is it possible to relate/link to other project files within the comments of the source code (C# in this case) in Visual Studio?
I've found you can use file:// hyperlinks, but those need an absolute path (plus they won't open in the code editor)... there's also <see cref>, which works with R#, but that relates to a symbol that must be referenced by the current project, so that doesn't work in my case.
For my specific case, I'd like to somehow relate Entity Framework's entity POCOs to their mapping configuration class (which resides in other project file which is not referenced by the project where the POCOs are defined).
Absolute paths won't work since this project is being worked on several computers with different absolute paths.
There's also HyperAddin but doesn't seem to have been updated since VS 2008, I'm using 2015.
Any ideas, or add-ins you might have used?
You can automate it with Visual Commander. The simplest command (C#) that requires you to select the relative configuration class file path in the editor (like Project1\config.xml) before calling it:
EnvDTE.TextSelection ts = DTE.ActiveDocument.Selection as EnvDTE.TextSelection;
string relativePath = ts.Text;
string absolutePath = System.IO.Path.Combine(System.IO.Path.GetDirectoryName(DTE.Solution.FileName), relativePath);
DTE.ItemOperations.OpenFile(absolutePath, null);
I am running a VBScript as a Custom Action at the Commit part of an MSI installation. The script calls an .exe that installs drivers for a ZB device. What I want to do is check the file system first to see if the drivers are already there and skip the installation if they are.
So far the script looks like this:
Sub Run(ByVal sFile)
Dim shell
Set shell = CreateObject("WScript.Shell")
shell.Run Chr(34) & sFile & Chr(34), 1, false
Set shell = Nothing
End Sub
Set objFSO = CreateObject("Scripting.FileSystemObject")
IF objFSO.fileExists("c:\windows\system32\drivers\ftser2k.sys") THEN
MsgBox("You already have the drivers installed.")
ELSEIF objFSO.fileExists("c:\windows\system32\ftserui2.dll") THEN
MsgBox("You already have the drivers installed.")
ELSE
Run Session.Property("CustomActionData") & "CDM20600.exe"
END IF
These files do exist on my machine. So if I double click the vbs file I get the MsgBox coming saying that I already have the file. However, when I run the msi installation, no matter what it installs the driver as if the first two conditional statements weren't even there. I did read that you cannot use the WScript object in MSI, so I took out the WScript.Echo lines and replaced them with MsgBox. I was wondering if maybe you can't use the FileSystemObject in msi either.
My ultimate goal is not to have any message come up. I just want the driver install to be skipped if the files are present on the system. The messages are there just for debug purposes right now.
If it helps, the msi package was built in Visual Studio 2010. Also the CustomActionData is the TARGETDIR.
I am new to both VBScript and install packages, so please be gentle :)
I have to be honest, I have many concerns about your proposed solution:
1) VB/JScript CA's Suck. I would read the link and take it to heart.
2) I've seen many machines in my career where the FSO was broken.
3) You've hard coded the path to System32 instead of using SystemFolder or System64Folder.
4) Commit custom actions don't execute when rollback is disabled.
5) You are running double out of process with no error logging of the EXE call.
6) Visual Studio Deployment Projects suck in so many ways that I can't count. Evidence is that Micrsoft has killed them in Visual Studio 11.
If it was me, I'd ask if you have to use this EXE to install the driver package or if there's an INF file to go along with the SYS/DLL files. If so, I'd look at create a WiX merge module that uses the DifxAppExtension. This allows you to encapsulate the behavior of driver installation in a discrete module and then add it to your VDPROJ installer or even better a WiX or InstallShield Limited Edition ( free ) installer.
Here are several blog articles that should help you understand what I mean:
Augmenting InstallShield using Windows Installer XML - Certificates
Augmenting InstallShield using Windows Installer XML - Windows Services
Redemption of Visual Studio Deployment Projects
I am trying to create empty solution file for Visual studio 2010 but I am unable to do so?
We used to create empty solution file for vs2008 by
EnvDTE::_SolutionPtr ptrSoln(_T("VisualStudio.Solution.9.0")); but I am unable to find equivalent for VS2010.
I was able to find how to create project but not Solutions?
I found the answer. Answer lies in previous question mentioned by me - How can I create new blank solution in vs 2008 programmatically?
I forgot to add reference to EnvDTE, EnvDTE80. EnvDTE90 and EnvDTE100 assembly. Also name of solution class is Solution4 instead of Solution3. So code snippet which works is:
string visualStudioProgID = "VisualStudio.Solution.10.0";
Type solutionObjectType = System.Type.GetTypeFromProgID(visualStudioProgID, true);
object obj = System.Activator.CreateInstance(solutionObjectType, true);
Solution4 solutionObject = (Solution4)obj;
solutionObject.Create("C:/", "Test");
solutionObject.SaveAs(#"C:/Test.sln");
Not 100% sure what you're asking. If you just want an empty solution with some pre-created folders, which would be a file just named yourProject.sln, go to whatever primary language you have installed (C++ in my case), and make an empty project. This will give you an empty solution file, with just one folder, it would be named yourProject in my case above, and a few project files related to the language. If you want to add a new project to this solution, go to:
File->Add->New Project. Fill in the rest with whatever application type your project/program needs to be. This is how it's done in C++, I don't know how to do it in, say C#. However, you didn't specify a language... So I'm not sure where to go to help you, Visual Basic? C++?
I am using a text editor to manually edit my *.sln file. I am confused about the following lines:
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Test2008", "Tools\Test2008\Test2008\Test2008.csproj", "{00B5EBB2-FDA5-4B23-BDC5-27E9F82E7C69}"
ProjectSection(ProjectDependencies) = postProject
{82B9BEC0-C9CC-4423-B54F-61E3C4AF53D8} = {82B9BEC0-C9CC-4423-B54F-61E3C4AF53D8}
EndProjectSection
EndProject
What's the point of this
{82B9BEC0-C9CC-4423-B54F-61E3C4AF53D8} = {82B9BEC0-C9CC-4423-B54F-61E3C4AF53D8}
statement? It looks totally superfluous.
The {82B9BEC0-C9CC-4423-B54F-61E3C4AF53D8} = {82B9BEC0-C9CC-4423-B54F-61E3C4AF53D8} line indicates that the Test2008 project has a declared dependency (set up via the Project Dependencies dialog in VStudio) on the project with the unique identifier 82B9BEC0-C9CC-4423-B54F-61E3C4AF53D8. You should be able to find a project with that same identifier in the same .sln file.
As for why the odd syntax of the line, I have no insider knowledge of the .sln file format. However, based on observation of other ProjectSection extracts in .sln files, I would have to guess that the .sln parser used by Visual Studio historically assumed that the ProjectSection lines will be in a key = value format, with key uniqueness enforced within any given section. I would also guess that the folks who implemented the project dependency functionality decided that, rather than mucking with the parser, it would be simpler to use projectId = projectId for their section lines since the keys are meaningless to them, but they are guaranteed to be unique if only one dependency from project A to project B is otherwise enforced.
It seems that this redundant syntax is one of the quirks required by MSBuild to recognize a project's dependency:
It appears that Visual Studio keeps
the dependencies in two ways, only one
of which is read by MSBuild. I see
that because I still can specify
dependencies in GUI, copy solution to
other machine and build it with VS in
correct order.
-Victor Sergienko
As for why this "superfluous equation statement" is required, it seems that assigning a project's guid to its own guid is a workaround for an issue with MSBuild 4.0 that causes MSBuild to not recognize or respond to certain project dependencies listed in a solution (.sln) file, or to build the dependencies out of order.
The screwed up "{x}={x}" syntax you're asking about is a variation of the standard MSBuild syntax for referencing a project (i.e. the example #Sergio's answer).
Apparently, embedding the dependency declaration in a ProjectSection block in conjunction with a self-named dependency GUID causes MSBuild to change the build order of the depended-upon project, but doesn't actually add another reference to it.
There's a discussion on Microsoft Connect wherein this workaround is discussed. In it, Dan from Microsoft suggests a cleaner workaround for this MSBuild glitch in his 2nd post on the page, and also mentions the fix you're asking about:
However, you can create a project reference that only [affects] the build order without [actually] adding [any runtime] reference. [Modify the dependent .csproj or .vbproj to] look like this; note the metadata element:
<ProjectReference Include="... foo.csproj">
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>
[...] That fixes the ordering, as now LibraryProject will wait on CodeGeneratingProject, but its build will otherwise not be affected. I can tidy up by removing the dependency in the solution file as well - removing these lines, which are now unnecessary:
ProjectSection(ProjectDependencies) = postProject
{B79CE0B0-565B-4BC5-8D28-8463A05F0EDC} = {B79CE0B0-565B-4BC5-8D28-8463A05F0EDC}
EndProjectSection
and it still works fine.
From MSDN:
This statement contains the unique
project GUID and the project type
GUID. This information is used by the
environment to find the project file
or files belonging to the solution,
and the VSPackage required for each
project.
The project GUID is passed to
IVsProjectFactory to load the specific
VSPackage related to the project, then
the project is loaded by the
VSPackage. In this case, the VSPackage
that is loaded for this project is
Visual Basic.
For example:
Project("{F184B08F-C81C-45F6-A57F-5ABD9991F28F}")
= "Project1", "Project1.vbproj", "{8CDD8387-B905-44A8-B5D5-07BB50E05BEA}"
EndProject
Lines after ProjectSection(ProjectDependencies) = postProject
specifies dependency list - which project depends on which. (Can be seen in Solution > Properties > Project Dependencies).
If you want to "decrypt" more what is happening inside, take a look at following project:
https://sourceforge.net/p/syncproj/code/HEAD/tree/
Here is .sln parser, you can check Solution.cs, search for "ProjectDependencies".
key is always same as value, this is some sort of file format issue.
I would like to search my VS 2008 solution and return back all files of .rpt files.
If possible, I would prefer it to be in code. I'd love to iterate over these files.
(This is for some maintenance of a solution that I inherited and has a lot of unreferenced code which I am attempting to clean up)
I'd use the FileInfo class, loop through all folders and files and build a list of all files with names that end with .rpt