I need to compile a source code, I've contacted the creator of the code and he told me this:
"You need the roslyn compiler, since it's written in C# 6.0."
I've got the roslyn compiler and I can't manage to make it work and/or compile anything
I've already tried to use MsBuild from VS 2015 but, unfortunally, w/out any success (as I get a lot of compiling errors)
If you are wondering what I'm trying to compile,here's the github https://github.com/frostycpu/FinalesFunkeln
I hope we can find a solution :)
Edit: Here's a screenshot of the console:
[]
I'm using the italian version of Windows, if you need translations ask me anything
My guess is you have some piece of software on your machine that defined the "Platform" environment variable, "helpfully" setting it to "HPD". MSBuild picks up that environment variable and is trying to build the HPD platform that is not defined in the solution.
The workaround is to build with msbuild /p="Any CPU". You could also uninstall the software or delete the environment variable, with the obvious caveat that who knows what the software does without that.
Related
I'm setting up some Visual Studio Solution, where I have some C# and C++ projects. I wonder if I can somehow simplify the CMake code which manages the dependency between the C++ target and the C# library.
It should work on Visual Studio 2015 with CMake 3.15. On this page I read that the target_link_libraries function should work the same for C++ and C# targets.
Old solution:
target_link_libraries(C++Target LINKING_TYPE CSharpLibrary)
target_compile_options(C++Target LINKING_TYPE "/AI${PATH_TO_DIR_WITH_CSHARP_DLL}")
Desired solution:
target_link_libraries(C++Target LINKING_TYPE CSharpLibrary)
Summary of results:
With old solution everything works properly, but to make it in this way I must have some "if" construction in my CMake to detect that added library is C# library.
When I make it in this desired way I get compilation error.
foo.cpp(10): fatal error C1107: could not find assembly 'C#Library.dll': please specify the assembly search path using /AI or by setting the LIBPATH environment variable
So I wonder if there is some way of simplifying this dependency adding? Maybe I can set some property of C#Library?
Update after comment of squareskittles:
My if-construction looks like this
if(NOT IS_IMPORTED)
if(DEPENDENCY_LANGUAGE STREQUAL CSharp)
target_compile_options(${TARGET} ${LINKING_TYPE} "/AI${PATH_TO_DIR_WITH_CSHARP_DLL}")
endif(DEPENDENCY_LANGUAGE STREQUAL CSharp)
endif(NOT IS_IMPORTED)
and of course I can use generator expressions, but I really don't know if it is human readable
target_compile_options(${TARGET} ${LINKING_TYPE} "$<$<AND:$<STREQUAL:${DEPENDENCY_LANGUAGE},CSharp>,$<NOT:$<BOOL:IS_IMPORTED>>>:/AI${IMPORT_DIR}>")
if-constructions seems to be more clear solution, than that.
I'm trying to have Code Analysis going for my .NET Standard 2.0 class library. As described here, I've added a reference to Microsoft.CodeAnalysis.FxCopAnalyzers. At the beginning, everything looked good and I started getting CA* warnings when building the project. However, after a while, these warnings disappeared although I hadn't touched the code.
Only after closing VS 2017, deleting all bin directories, restarting VS 2017, I started getting back the CA* warnings. However, this doesn't seem to be the recipe to get them back: in my CI environment, the same thing happened. I lost the warnings after an unrelated commit and I still didn't manage to bring them back although I've cleaned the checkout directory completely.
I wonder what could be the reason that at moments the Code Analysis stops working. Unfortunately, I haven't figured out a way to reproduce this - thus my question.
As a matter of fact, I'm eager to understand why adding a NuGet to a project can modify the outcome of the compilation process at all. How does that magic work? Any pointers are welcome.
As to how Roslyn Analyzers are loaded from NuGet
The new C# and VB compilers are based on Roslyn. Roslyn is an extensible compiler framework where a number of analyzers can run at different stages of the compilation process.
MsBuild will pass the analyzers references from the project file to the call to the Roslyn compiler, which will load these in turn and will execute them after the sources have been parsed and interpreted.
The NuGet packages have special metadata that ensures that these analyzers are added as a special type of reference to the MsBuild project file so that MsBuild can pass these along to the compiler.
As to why the analyzers sometimes fail
This is hard to say. Some metadata of projects is stored. Setting the options to clear the workspace/working directory and start afresh may fix this. Setting the build.clean variable to all should help with that. Deleting the bin, obj and .vs folder as well as the packages folder and performing a nuget restore + build should bring you back into a usable state.
The new FxCop analyzer project still isn't complete and is still being updated. A bug in the analyzer infrastructure can cause the analysis to fail. Unfortunately, this is generally very hard to debug. Turning off rules one by one may help you find the culprit.
There seems to be an option built into Roslyn to enable ETW Logging, which should give you a lot more details, but this isn't very well documented.
In Visual Studio there is another thing that can break the analyzers, Visual Studio Extensions can load analyzers as well, which Visual Studio will then inject into the build process. These extensions are not part of your project and thus won't show up in source control in any way. Any recently updated extension could thus also be the culprit. Setting the MsBuild verbosity level to Diagnostics should show you which analyzers are passed to csc, which should help you figure out where your problem may be coming from.
We're trying to switch a lot of projects over to use SDK7.1. This seems pretty straightforward with C++ projects, and you can change the 'Platform Toolset' property in the project settings to "Windows7.1SDK" and all is good.
But, with C# projects, (if you put the build output up to diagnostic mode), we can see that various tools such as sgen, resgen, LC, run from within a previous SDK 7.0A directory. Or, on some machines that we installed Vistual Studio 2012 on, some of these tools come from an v8.0A SDK folder.
Mismatches between the tools and the assemblies they produce seem to be causing various errors such as:
LC : error LC0000: 'Could not load file or assembly
'S:\Libraries\Bin\Release\Some.dll' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.'
It seems we can edit the .csproj files and almost ad-hoc, and BeforeBuild etc targets that redefine various SDKPath properties. This seems to force the right tools to be used. But, if feels very 'hacky'. And we must be missing setting something as we still get some errors.
Alternatively, we've found, we can change the registry value here:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0\SDK40ToolsPath
to point at the correct SDK. But, it feels wrong to have to modify the environment to support this. We want to build old versions of our product, and having to switch the environment around to do this is ugly and error prone.
Is there any official way of doing this?
Thanks.
P.S. I found this question http://social.msdn.microsoft.com/Forums/en-MY/windowssdk/thread/ebc8914f-d4b5-44e7-8c76-10332d155812 where the poster seems to be asking a similar thing, but, the question didn't seem to get answered.
The following two articles talk about defining custom tool sets. Perhaps one of those needs defining for the 7.1 SDK, and then MSBuild can be directed to use it.
http://msdn.microsoft.com/en-us/library/bb383796(v=vs.110).aspx
http://msdn.microsoft.com/en-us/library/bb397428.aspx
I feel like this is a question that's likely to have been answered already, but I'm having trouble finding it. Chalk it up to bad search terms, perhaps.
I've been working in Visual Studio 2005 Professional for about a month now, and thus far I've been using the built-in compile mechanism with mostly-default settings (the only thing I've changed with any real frequency is the build path). I'd like, however, to move to using more automated build techniques. To that end, I'd like to switch to using csc calls instead of hitting Ctrl-Shift-B or F5, so that I can include the lines in build scripts and other tools (like NAnt).
My question is, does Visual Studio or any third party tool provide a way to programmatically convert the compile setting ins VS to its csc equivalent? For example, if I have a project called SampleProject with the Output type: field set to Windows Application, it would look something like:
csc /output:winexe /target:SampleProject.exe *.cs
I know it's usually not terribly difficult to work this out by hand, but if there's a way to automatically pull it together, it's that much better.
Based on VS2010, but similar should work for other versions:
Tools > Options > Projects and Solutions > Build and Run
Change the "MSBuild project build output verbosity" to "Normal" (or higher)
Build, and bring up the Output window (ctrl+w, o).
Change the "Show output from" drop-down to "Build"
You should see an indicative csc line. Note this is not truly what it executed; it is a happy lie. IIRC it actually executes directly, and there are some corner-cases where what it outputs there is not quite the same as what you would need.
It would be nice if it did both a list of methods to choose from and the list of potential input parameters. This was done for powershell and I was curious if there was any similar functionality implemented for emacs or vim?
Clarification:
A fellow developer I work with wants to use either vim or emacs for the low overhead without running visual studio. In essence he would like to be able to write tests, edit code in emacs or vim then just run NANT scripts to compile the code and run the tests. The only feature from Visual Studio he wants is code completion. The rest he can live without for 98-99 percent of the time.
You can use a vim editor emulator for Visual Studio.
http://www.viemu.com/
I haven't come across an emacs mode that would offer code completion suggestions based on "knowledge" of the API(s) that the user's environment is offering. To a lot of people this is an issue which prevents them from attempting to use Emacs or VIM when working with rich/large/unwieldy (delete as applicable) APIs.
However I am wondering how much of a problem this would present during day-to-day work. I've been using Emacs with C#-mode to crank out quite a lot of C# code. I also tend to run dabbrev-mode or pabbrev-mode, which tends to take care of the more common function and variable names I tend to use. To my eternal shame I have to admit that I tend to have a browser open on the MSDN website to look up the rest - those APIs that I don't use often enough to remember. Another potential helper that your colleague might want to look into is icicles, which may also be a step in the right direction. Neither of these libraries however will offer the full breadth of completion support that something the like Visual Studio IDE will offer. I'd see this as part of the trade-off when using a more efficient editor.
As an aside, if your colleague is working in a team and other members working on the same project are using Visual Studio, MSBuild might offer a better solution for building outside of VS than Nant as MSBuild reads the same solution and project files that VS uses (in fact a lot of the build work in VS2008 is handled by MSBuild). The syntax isn't too far away from Nant and with the community tasks added (which gives you NUnit integration etc) and it'll ensure that everybody is using very similar mechanisms to build the executables.
The furthest along completion I've seen for C# is at this blog, specifically at this post. (Blog link included for context and other Emacs posts.)
If you can live with dumb completion, you might be able to roll your own with tags and tag completion.
A previous stack on the same issue.
Your source code should be processed through the CEDET framework: http://cedet.sourceforge.net/
Then either use the example UIs bundled with cedet or else try any of these two:
- company-mode: http://nschum.de/src/emacs/company-mode
- completion-ui: http://www.dr-qubit.org/emacs.php
both supporting CEDET as a completion search backend.
apa!
for emacs and C# you can look at this tool : http://code.google.com/p/idebridge/
OmniSharp provides contextual intellisense for C# in vim.
Some of the suggestions in Eclipse Style Function Completions in Emacs for C, C++ and JAVA? may be relevant for emacs.
Not c# specific, but still.
I have found the http://code.google.com/p/csense this is an emacs c# intellisense/code sense. I found it from this blog post http://osdir.com/ml/emacs.sources/2007-11/msg00018.html, this may be close to the answer I was looking for.
After looking further it has not been updated since November 2007, looks stale to me.
For Vim, you can install insenvim. It support for the C# code completion.
After download the plugin you could install the installation file or install manually by following steps:
Copy the file cs_vis.vim into your $VIM\vimfiles\ftplugin directory.
Copy the file csft.dll into your $VIM_INTELLISENSE directory.
Copy CSVimHelper.dll,reg.bat to your $VIM_INTELLISENSE directory.
Run reg.bat to register the dlls. You need to set the directory gacutil.exe
in the path. You need the latest version of .NET SDK.