F# compilation errors in Azure only when deployed from GitHub - azure

I'm deploying a C# website to Azure from a GitHub repository. This website references a couple of F# libraries and they compile just fine on my machine, but in Azure the build fails with a number of compilation errors.
Here is a snippet of the build log:
FS0001: A generic construct requires that the type 'Company' have a public default constructor [C:\DWASFiles\Sites\eureka-servicestack-poc\VirtualDirectory0\site\repository\Eureka.ServiceStack.FSharp.Poc\Services\Services.fsproj]
C:\DWASFiles\Sites\eureka-servicestack-poc\VirtualDirectory0\site\repository\Eureka.ServiceStack.FSharp.Poc\Services\CompaniesService.fs(28,17): error FS0039: The field, constructor or member 'PopulateWith' is not defined [C:\DWASFiles\Sites\eureka-servicestack-poc\VirtualDirectory0\site\repository\Eureka.ServiceStack.FSharp.Poc\Services\Services.fsproj]
C:\DWASFiles\Sites\eureka-servicestack-poc\VirtualDirectory0\site\repository\Eureka.ServiceStack.FSharp.Poc\Services\AppHost.fs(17,55): error FS0072: Lookup on object of indeterminate type based on information prior to this program point. A type annotation may be needed prior to this program point to constrain the type of the object. This may allow the lookup to be resolved. [C:\DWASFiles\Sites\eureka-servicestack-poc\VirtualDirectory0\site\repository\Eureka.ServiceStack.FSharp.Poc\Services\Services.fsproj]
An error has occurred during web site deployment.
The first error should have been fixed after I put the CLIMutable attribute on the offending record type and the second error should have been fixed after including the proper namespace. I don't know what exactly the third error is about, especially since none of them happen locally.
To make sure I had the same version of F# in both places I've included the FSharp.Core dll in the solution and refer to the local version. This did not help but it removed a warning that it could not find version 4.3.1 of the file.
Is it possible that I'm running another version of the F# compiler and how do I check that? It has worked fine until now, which makes me suspect some slight difference in versioning of something. Unfortunately it seems quite hard to get insight into what actually happens in the build environment. It is a free website Azure website and it does not seem like you cen get direct access to it.
I could probably work around the individual issues for now but there seems to be a deeper issue at work here.

This turned out to be an issue with different versions of the F# compiler being used. Using Visual Studio 2013 RC, I was using the 3.1 version, which has had some improvements causing my specific issues to not appear.
The problem was made difficult to identify because changing my F# project to use the 3.0 compiler in Visual Studio did not have any effect (it still compiled just fine). I even opened the solution up in Visual Studio 2012, and it all compiled well enough. It was only when I created a new project from scratch in VS 2012 that I began to get the same compilation errors as on the server. So I guess that this must be an error (or at least not very desirable feature) in the project file that was created. I'm not sure if this should be classified as a bug with VS 2013, especially since I don't know exactly what causes the error.
So the simple solution until Azure (or is this a Kudu thing?) supports the 3.1 compiler is to either recreate the project file in VS 2012 or to copy code which does not compile over to a test solution where fixes can be tested.

Related

Visual Studio 2015 code map external dependencies

I have a native Win32 project written in C and wanted to visualize my project's dependencies from external DLLs. Visual Studio 2012 and 2013 let me generate a code map which would not only show all my functions and their dependencies from each other using arrows, but also all external libraries I used, which functions I used from those and which of my functions called which external functions etc..
Now, in Visual Studio 2015, this latter part seems to be missing. I can not get Visual Studio to show my project's external dependencies. I only see the internal ones. So here's my questions: Am I missing something? Do I have to activate a specific option in my project settings? Or are those external dependencies just not working in Visual Studio 2015 right now?
Steps to reproduce: Create a new non-empty Win32-project. In the Architecture menu, select Generate code map for solution. You will only see Win32Project1.exe in the middle of the screen. Meanwhile, Visual C# seems to be fine, showing the external dependencies. Create any C#-project for comparison.
Thank you for taking the time to post this! This looks like a regression, as in Visual Studio 2013 an Externals group with external dependencies is shown for C++.
I've logged a bug on Microsoft Connect so that you're able to track this externally:
https://connect.microsoft.com/VisualStudio/feedback/details/1694695
I have posted this workaround on the link that Bogdan Gavril listed and hope it helps someone. Unfortunately, it requires that you enable "CLR" support for your project. Basically, it appears that the VC++ linker and librarian is looking for a flag that indicates some type of managed code. At the very least, the code map is dependent on the mscorlib.dll reference injection. To make the CLR issue (which adds a lot of unnecessary bulk for native code) less a problem, simply create a new build configuration for use only when you need code maps with external dependencies. Make sure you've selected "CLR Support" on the general options of the project properties configuration page. Then, clean (probably not necessary) your solution and generate a code map. You will find the external dependencies as expected!
Zac

Failed to resolve System.Void UIKit.UITableView in Xamarin iOS

If I build my Visual Studio project for Xamarin.iOS with the Linker Behaviour set to "Don't Link", everything works fine except the resultant IPA file is 30MB (which expands to 101MB on the app store!).
If I change the Linker Behaviour to anything else (Link All or Link SDK) then I receive the following compile error;
Error 32 Failed to resolve "System.Void UIKit.UITableView::set_DataSource(UIKit.UITableViewDataSource)" reference from "Xamarin.iOS, Version=0.0.0.0, Culture=neutral, PublicKeyToken=84e04ff9cfb79065"
I want to use the linker so that the size of the project comes down to a respectable size. Can anyone elp with this error?
The issue was because your older version of sqlite was based on an older (preview) version of the unified API.
Some API signatures changed like, in the case, to allow using protocols more easily (which means using interfaces instead of types).
Note that turning off the linker will remove the build failure - but that symbol is still missing and you can run into this at runtime (which is worse since you'll need to test carefully to ensure that does not get hit).
I removed the reference to sqlite and re-added it again through nuget. This resolved the issue.

Windows Work flow assemblies not picking up

We we trying to create a work flow dll using Windows Work Flow but we are running into major problems regarding referencing.
1.) We have a class that calls an activity but the class cannot pick up the activity that has already been created
WorkflowAcivity workflowActivity = new WorkflowActivity(string id)
This then throws an error message saying cannot find WorkflowActivity
2.) We then added extra assemblies, like one of our other dll's, Visual Studio also cant find these references when we call a class in those dll's we are referencing.
3.) Intellisence has also stopped working??
What do we do to fix this, is it the version we are using or are there any other assemblies we are missing here??
We have tried opeing the solution on another pc, uninstalled vs 2012 and installed vs 2013 and still have no luck!
Got caused by System.Net.Http.Primitives.dll referencing some dll's that were missing and caused the workflow to break without any warnings.
Removing this dll or adding the referenced dlls back in (System.Runtime.dll and System.Runtime.InteropServices.dll) fixed the problem.
Microsoft ticket for this.

MonoDevelop unsupported project type vcxproj

I have been a long-time visual studio developer, and I am trying to switch over to using mono so I can port my applications to Ubuntu. I have been trying to get some of my VS2010 C++ projects (.vcxproj file types) to load into MD on my Ubunutu 12.04 machine. According to the documentation I have read online this should work, however, every time I try and load a project I get the error shown below. Is there something else I need to be installing in order to be able to load C++ projects in monodevelop? I have done some searching, but have not yet found anything related to this particular question.
VC2010Test.sln(4): Unsupported or unrecognized project : '/home/me/Projects/Test/VC2010Test/VC2010Test.vcxproj'.
Thanks
MonoDevelop has a C/C++ binding, called CBinding.
But:
Beware, it's not meant to target managed C++.
AFAIK, it only works in Unix-like platforms.
So, if you still target non-managed C++ and are not using MonoDevelop for Windows, two questions:
Did you make sure that the binding (addin) is installed and enabled?
If the answer to the above question is yes, you may want to try this: the binding creates projects with the extension ".proj" by default, I think, so maybe you can change this to ".vcxproj", recompile, and test again. If it works, then it should be easy to create a pull request to include this extension of possible file types that this addin can handle?

Building Ocean 2011 plugins with Visual Studio 11 Beta - issue with InventorNet.dll

I've started testing VS11 beta for building Ocean 2011 plugins. It seems to work very well, and has enough advantages that I'm considering using it for daily work. (We will, of course, not make production builds with VS11 before Schlumberger recommends it.)
However, there is one blocking issue:
Projects which depend on InventorNet.dll fail to build, with the following messages:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1546,5): warning MSB3270: There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "InventorNet", "AMD64". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.
CSC : fatal error CS0008: Unexpected error reading metadata from file 'c:\Program Files\Schlumberger\Petrel 2011\InventorNet.dll' -- 'Index not found.'*
I think the first warning is harmless, as similar warnings are emitted from other dependencies, but I can't get past the error message (in bold). Both probably originate from stricter assembly verification in .NET 4.5 (also in beta) used by MSBuild. Our projects target .NET 3.5.
Does anyone know if the error can be fixed with some setting or other trick, or do we need updated assemblies from Schlumberger? (A Google search yields a few similar cases relating to VS2010, and indicates that the assembly provider does, indeed, need to rebuild the assembly to correct the issue.)
Alternatively, can someone indicate whether the issue will be remedied by Ocean 2012?
I just simply test your case for petre/ocean 2012 D9 snapshot version with OIV 9.0.0.0(for 2011, it is 8.1.2.2), it seems that it works fine(passed building with some warnings in visual studio 2011, and running OK in Petrel 2012 D9)。
Deng Feng
Just about warnings for Ocean 2012 in VS11beta: it can be "CPU mismatch" warning if your solution has "Any CPU" target and based on top of Petrel 64 (Because Inventor's DLLs are CPU dependent). And it will be no warnings if you select 64 bit CPU target for your project.
Alex
first warning can be eliminated by adding the following string to your .csproj file:
<PlatformTarget Condition=" '$(PlatformTarget)' == '' ">x86</PlatformTarget>
I added it inside node, after node

Resources