This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: -6225: Resolving Visual Studio .NET project output
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
Apr 25, 2013
11:39 AM
-6225: Resolving Visual Studio .NET project output
Hello,
I am using Visual Studio 2012 (VS) and IS 2012 SE. I have created a Basic Setup Project in VS and it is working fine. But when I use VS command line tool to build the project I am getting below error.
ISDEV : error : -6225: Resolving Visual Studio .NET project output "MyProject\MyProject.csproj\|Built"
Here is what command at command line looks like.
devenv.com /build "Debug|Any CPU" "C:\Build\Full Project Path\MySolution.sln"
Can you please help resolve this error?
Thanks
Jignasu
I am using Visual Studio 2012 (VS) and IS 2012 SE. I have created a Basic Setup Project in VS and it is working fine. But when I use VS command line tool to build the project I am getting below error.
ISDEV : error : -6225: Resolving Visual Studio .NET project output "MyProject\MyProject.csproj\|Built"
Here is what command at command line looks like.
devenv.com /build "Debug|Any CPU" "C:\Build\Full Project Path\MySolution.sln"
Can you please help resolve this error?
Thanks
Jignasu
(10) Replies
Apr 25, 2013
04:51 PM
It is a bug introduced in Visual Studio 2012. Currently the accessing of project output groups from the Devenv.exe command line build for C# is disabled. For a workaround, try using MSBuild to build your projects.
Apr 25, 2013
06:09 PM
Hello,
Thanks for the reply. I tried MSBuild and I am getting some error. Is there an open connect bug with Microsoft? Below is the error message I am getting.
C:\Program Files (x86)\MSBuild\InstallShield\2012Spring\InstallShield.targets(11,3): error MSB4062: The "Microsoft.Build.Tasks.AssignProjectConfiguration" task could not be loaded from the assembly Microsoft.Build.Tasks.v3.5. Could not load file or assembly 'Microsoft.Build.Tasks.v3.5' or one of its dependencies. The system cannot find the file specified. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
Thanks
Jignasu
Thanks for the reply. I tried MSBuild and I am getting some error. Is there an open connect bug with Microsoft? Below is the error message I am getting.
C:\Program Files (x86)\MSBuild\InstallShield\2012Spring\InstallShield.targets(11,3): error MSB4062: The "Microsoft.Build.Tasks.AssignProjectConfiguration" task could not be loaded from the assembly Microsoft.Build.Tasks.v3.5. Could not load file or assembly 'Microsoft.Build.Tasks.v3.5' or one of its dependencies. The system cannot find the file specified. Confirm that the
Thanks
Jignasu
Apr 26, 2013
03:23 AM
Hi
We always get this especially that our projects are under TFS source control when we resave a change or open solution in VS2012.
We are targetting .NET 4.0 and fix this problem (locally on dev machine and buiild server) by using C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe.
We then open up the *.isproj file and change the ToolsVersion="3.5" on top line to ToolsVersion="4.0" and it recompiles
unsure whether fault is VS and/or IS.
Cheers
kyle
We always get this especially that our projects are under TFS source control when we resave a change or open solution in VS2012.
We are targetting .NET 4.0 and fix this problem (locally on dev machine and buiild server) by using C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe.
We then open up the *.isproj file and change the ToolsVersion="3.5" on top line to ToolsVersion="4.0" and it recompiles
unsure whether fault is VS and/or IS.
Cheers
kyle
Apr 26, 2013
11:48 AM
Hi Kyle,
Yes we are using VS2012, but ISPROJ file still has. But my machine is 64bit and it is using C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe vs Framework64. Not sure if there is a way to change that for me.
Thanks for your reply.
Jignasu
Yes we are using VS2012, but ISPROJ file still has
Thanks for your reply.
Jignasu
Apr 26, 2013
12:41 PM
jignasuk wrote:
Hi Kyle,
Yes we are using VS2012, but ISPROJ file still has. But my machine is 64bit and it is using C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe vs Framework64. Not sure if there is a way to change that for me.
Thanks for your reply.
Jignasu
If you manually update the tools version as I said does it compile? Thats enough to set you on but you may have to constantly do until a patch comes out else update the relevant msbuild.targets file. Ive forgot whcih one it is
Sep 13, 2013
11:42 AM
I initially used the suggestion from Kyle about manually updating the ToolsVersion value to "4.0" in the isproj file to fix a build issue (TFS 2012).
However, as Kyle pointed out "but you may have to [change the ToolsVersion constantly] ... until a patch" is available. After fixing this 3 days in a row for our release builds, I needed to find a more permanent solution.
The following work-around worked for me; hopefully it will work for others too:
- Notes:
A.) Tested using TFS2012 on 64-bit Win2008R2 machine; I think that this will work for TFS2010 too, but don't have one to test it on.
B.) All of my projects can use the ToolsVersion 4.0 so this is safe for me; that might not be the case for your solution - your mileage might vary (YMMV)
- Make sure that your project file has ToolsVersion="3.5" at the top
- Make sure that your latest build failed for the ToolsVersion 3.5 issue
- Open your TFS Build Definition
- Go to Process tab
- Expand #3 Advanced
- Go to the MSBuild Arguments
- Put in the following (can also be abbreviated /tv, but I like using the full word to avoid any confusion):
/toolsversion:4.0
- Queue up a new build
- This time it should succeed (or at least get beyond the ToolsVersion 3.5 error message)
However, as Kyle pointed out "but you may have to [change the ToolsVersion constantly] ... until a patch" is available. After fixing this 3 days in a row for our release builds, I needed to find a more permanent solution.
The following work-around worked for me; hopefully it will work for others too:
- Notes:
A.) Tested using TFS2012 on 64-bit Win2008R2 machine; I think that this will work for TFS2010 too, but don't have one to test it on.
B.) All of my projects can use the ToolsVersion 4.0 so this is safe for me; that might not be the case for your solution - your mileage might vary (YMMV)
- Make sure that your project file has ToolsVersion="3.5" at the top
- Make sure that your latest build failed for the ToolsVersion 3.5 issue
- Open your TFS Build Definition
- Go to Process tab
- Expand #3 Advanced
- Go to the MSBuild Arguments
- Put in the following (can also be abbreviated /tv, but I like using the full word to avoid any confusion):
/toolsversion:4.0
- Queue up a new build
- This time it should succeed (or at least get beyond the ToolsVersion 3.5 error message)
Apr 15, 2021
03:45 PM
I am using InstallShield 2020 R3 and Visual Studio 2017 and i am seeing this error.
1) Initially I updated my *.isproj to change the ToolsVersion from 3.5 to 4.0 but this does not seem to work. Also I don't know why it keeps going back to 3.5.
2) After the error occur , I have to go to Visual Studio->open the project->Application->Output type and change the value either Class Library or Windows Application (depending on where it was set) and then rebuild then error is gone, any idea why?
Sep 13, 2013
12:50 PM
Just in case anyone needs it, here is the MSDN article that I used to determine the information that I posted:
http://msdn.microsoft.com/en-us/library/vstudio/bb383985.aspx
http://msdn.microsoft.com/en-us/library/vstudio/bb383985.aspx