After porting a medium sized C/C++ application with a few libraries to VS 2010, I am getting the following error (Configuration: Debug, Platform: Win32):
LINK : fatal error LNK1104: cannot open file
'D:\projects\Libraries\SDL_image-1.2.7\VC10\Debug\Win32\SDL_image.lib'
I have quadruple checked SDL_net project settings in VS 2010. The folder name is correct, there are no folders containing blanks anywhere in the entire solution, etc. The DLL's object files are all in that folder (as they should be). Yet the import library cannot be created. This stuff works fine in VS 2008.
There are other similarly setup libraries in the solution (like SDL_mixer, SDL_net) and I don't have this problem with them.
How can I possibly fix this?
Check the vcxproj file - it seems like VS2010 adds reference to the project it self. I found following section at the end:
<ItemGroup>
<ProjectReference Include="XXXXXXXX.vcxproj">
<Project>{00e4326ce-9477-46e2-9133-43566aeec84e}</Project>
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>
</ItemGroup>
Where XXXXX is the project name. After removing it everything went fine.
Related
I have a solution with multiple web projects. And there is common tsconfig which is used to build all typescript in solution. Build is called via webpack, so I don't want any typescript support from visual studio. More precisely, I want some support — in navigating and refactoring, but I don't want VS to build this code.
So I removed all references to typescript targets from csproj and everything works fine. But any time I add a new typescript file, VS gladly says
Your project has been configured to support TypeScript
and returns all typescript targets back to csproj.
Can I prevent VS from doing it? Of course I can live with it, but removing garbage from csproj after each adding seems uncomfortable.
UPD: found post on uservoice of VS https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/13420095-ask-to-configure-projects-for-typescript. But maybe there is solution already available. Or you can like this uservoice if you agree that it is an annoying problem :)
Found solution on uservoice (https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/13420095-ask-to-configure-projects-for-typescript).
Seems a bit ugly but it works.
Steps to fix:
Add some ts file to project and let VS add some bullshit to your csproj
ctrl-shift-s to make sure csproj is updated
Open csproj in any text editor and then:
Find import of Microsoft.TypeScript.Default.props and replace it's Condition="..." to Condition="false"
Remove line with TypeScriptToolsVersion
Find import of Microsoft.TypeScript.targets and replace it's Condition="..." to Condition="false"
Now after adding file VS will stop trying to do smth with project. And typescript will not be compiled on save and build, so you need to use gulp/webpack/grunt/whatever.
Visual Studio 2019 (16)
Add to *.csproj file
<ItemGroup>
<None Remove="**/*.ts" />
<Content Remove="**/*.ts" />
<TypeScriptCompile Include="**/*.ts" />
</ItemGroup>
Solution is described here: https://developercommunity.visualstudio.com/t/vs-modifies-csproj-file-with-typescriptcompile-ite/288648
I'm trying to import a targets file from a relative path. The targets file is containing version information. The goal is not to have to modify all the thousands of projects files that we have when we create a new branch and have a new assembly version. We need the assembly versions because 2 version of the system can be installed at the same time and we have dlls in the global assembly cache.
Here's what it looks like in the project file:
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="..\..\..\..\..\..\Versions.targets" />
...
<ItemGroup>
<Reference Include="MyDll, Version=$(VersionAssemblies), Culture=neutral, processorArchitecture=MSIL">
<HintPath>..\..\..\..\..\..\..\..\..\..\Apps\$(CodeVersion)\DEVP\appl\BinApps\MyDll.dll</HintPath>
</Reference>
</ItemGroup>
...
</Project>
This is working fine if I'm working with a .vbproj. But the issue is that we have a lot of old .cobproj Cobol project files. For some reason, it seems like Visual Studio 2010 don't set the working directory when opening a cobproj, so it's unable to reach Versions.targets...
If I rename my cobproj to use vbproj as extension, it's working fine. So it's definitively something that Visual Studio is doing when a project of a known extension is opened, but I've searched a lot and I didn't find where I could add cobproj to tell Visual Studio that it's a known extension.
Another interesting fact, it that if I double click on my cobproj, it's working, because the working directory is already set to the directory in which the cobproj is... If I open Visual Studio and then do a File/Open and select my cobproj, then it's not working.
I'm wondering if someone may know how I could fix my issue without changing the extention of all my cobproj. I'd like a cleaner solution.
Thanks!
I've found a workaround, if I modify the Project Type Guid in the .sln, I can make Visual Studio act with my .cobproj like it would with a .vbproj, at least regarding the working directory setting.
From the .sln file:
Project("{F184B08F-C81C-45F6-A57F-5ABD9991F28F}") = "appsEXCI.Donnees.Containers.Cobol", "appsEXCI.Donnees.Containers.Cobol.cobproj", "{54E1DEC4-8919-40F6-B7BB-C936921B221F}"
EndProject
I'm rather unfamiliar with programming tools in Windows but have been forced to use VC++ 2010 Express for a project recently. We have been working on a piece of software that we didn't start and now we are reaching the finish line. Only problem is that I want to be able to set the executable icon.
Since the project is written mostly in SDL we have set the titlebar icon using the SDL_WM_SetIcon call as recommende on several sites but I still can't find any references to how to set the executable icon. All my google searches has turned up results about Visual Studio 2010 and Visual C++ 2008, neither of which seems appicable.
Since VC++ 2010 Express lacks resource editor but not resource compiler this can be done by manually creating a resource.rc file in the project directory (same as where your .vcxproj files are located), also drop in your .ico version of your icon in the same directory.
In resource.rc add the following line:
IDI_APP ICON "icon.ico"
And add the file, in VC++, to the Resource Files.
Doing this in VC++ should result in something like this to be added to your .vcxproj:
<ItemGroup>
<ResourceCompile Include="resource.rc" />
</ItemGroup>
And to your vcxproj.filters:
<ItemGroup>
<ResourceCompile Include="resource.rc">
<Filter>Resource Files</Filter>
</ResourceCompile>
</ItemGroup>
I ran into a similar situation recently with the Express edition.
I came up with a different way to approach this (see gif).
Posting it here in case someone runs into similar problem.
I have an asp.net mvc web application, and i have a reference to SharpArch.Web (one of the Sharp Architecture assemblies)
When i rebuild the project, and run it, an exception is thrown telling me that the (Newtonsoft.Json.dll) is missing from the Bin folder which is used by (SharpArch.Web), so it's ok, i copied it, and every thing worked well.
When i try to rebuild the project again, the exception is thrown again, and the (Newtonsoft.Json.dll) assembly is deleted ??
Why did that happen? what does visual studio have to do with non-referenced assembly ?
and FYI, VS doesn't delete everything from Bin, just a specific assemblies !!!
and BTW i don't want to add a reference to (Newtonsoft.Json.dll), i don't like to reference an unused assembly.
I had the same situation on one solution I was working on. So I ended up putting those .dll's into a separate folder. In my case I named this folder "ServerAssemblies". Then I modifyed my project file (.csproj in my case) and added an "AfterRebuild" target. That way there is noe need to add references to unused assemblies to the project.
<Target Name="AfterRebuild">
<ItemGroup>
<ExtraAssemblies Include="$(SolutionDir)ServerAssemblies\**\*.*"/>
</ItemGroup>
<Copy SourceFiles="#(ExtraAssemblies)" DestinationFolder="$(ProjectDir)bin\"></Copy>
</Target>
I suppose that the Bin\ directory is reserved for mangling by Visual Studio. You'll have to put your assembly in a different location.
We're using Jon Skeet's proto-csharp-port, and I'm running into some difficulties when mixing it with ReSharper in Visual Studio 2010.
We generate the .cs files via a custom MSBuild target, hooked up as follows:
<Target Name="BeforeBuild" DependsOnTargets="CompileProtos" />
The CompileProtos target runs ProtoGen and then adds the generated .cs files to the #(Compile) item group, by using CreateItem. This looks in a defined directory and compiles every .proto file it finds, so they're not listed in the project.
Where it falls down is that ReSharper doesn't recognise the content of the .cs files (because they're not in the project and might not exist yet), so I can't get the solution analysis light to go green.
If I add the .cs files to the project, then I get a build failure, because the .cs file has been added to the Compile item group twice.
I know that Marc's protobuf-net has Visual Studio 2008 goodness in it, and I'm looking for something similar, but for Jon's protobuf-csharp-port and for Visual Studio 2010.
Ideally, I'd like to be able to add the .proto files to the project, have them built correctly, and have Visual Studio and ReSharper know about the generated .cs files, so that IntelliSense and solution analysis work properly.
I'm guessing that something like how .xsd files can implicitly generate .cs files would do the trick.
I've attempted to get this working by implementing a custom tool for code generation, but I've run into a seemingly insurmountable hurdle:
protoc takes a directory full of .proto files and generates a .protobin file. This is then fed to ProtoGen which spits out a .cs file for each protocol definition. Unfortunately, it appears that the .protobin file needs to contain all of the definitions, otherwise you get Error: Unable to resolve all dependencies.
Since the custom tool model in Visual Studio assumes a single input file and a single output file (i.e. foo.proto -> foo.cs), it doesn't look like this can be made to work.
At least, not without finding some way to include all of foo.proto's imported .proto files in foo.protobin, anyway.
I solved it by removing the CreateItem from the CompileProtos target, and by defining it as a proper ItemGroup:
<ItemGroup>
<Protocols Include="$(ProtocolsPath)\*.proto"/>
</ItemGroup>
<ItemGroup>
<Compile Include="#(Protocols -> '%(Filename).cs')"/>
</ItemGroup>
This means that Visual Studio (and ReSharper) pick up the .cs files correctly, once they've been built, and ReSharper's full solution analysis stops complaining.
Unfortunately, Visual Studio has a habit of expanding the ItemGroup into individual Compile entries, but I can check for that before checking anything in.