I have a SharePoint Visual Studio project (SharePoint 2010, Visual Studio 2012) that deploys as a Farm solution, not Sandboxed. There are a couple of other class libraries in the solution that have a strong name and are included in the package under the Advanced tab. The project builds fine. However, when I deploy it, the using references to the other dll's break and the deploy fails.
Here's the wierd part: it is only breaking in one of the class libraries.
I have the following projects in my solution:
* MyProject.View (the SharePoint project with visual web parts)
* MyProject.Presenter (this is the one that's breaking)
* MyProject.Data
* MyProject.Model
I set up a sample web part that used the MyProject.Model class library and all was well. But when the .View project references the .Presenter library, the .Presenter library loses references to .Model and .Data.
Does anyone have an idea on what I should check?
Related
I have a solution that consists of 5 projects (ASP.net Core Webservice and dlls). For this solution I want to create a setup using WiX. I'm working with Visual Studio 2019.
The solution is located in a Git repository in Azure DevOps.
There is already an automated build process that is executed after each pull request.
I want to extend this process (or create an additional one) so that the setup is also created automatically after the build.
Should I add the setup as another project to the existing solution or should I create a separate solution?
I don't have any experience with creating build pipelines in AzureDevOps yet, so I'm afraid that I might run into problems there later if I choose the "wrong" variant now.
What are the advantages and disadvantages of the two variants?
Are there best practices for when to use which?
This is a matter of personal choice but after 20+ years of installation development I prefer two solutions. The reasons are:
Pros:
It helps organize the repos to have Application code and Installer code.
Application developers don't have to have WiX installed. Projects won't fail to load in the application solution.
The application sln can be updated to a newer version of Visual Studio without waiting for the installation toolset to support the new version. This has historically been an issue.
Project dependency / project build order issues are moot because all application projects will build before any installer projects will.
Application developers don't have to worry about installer developers messing up their projects.
Because the projects are in different solutions you can't use project references which can be tricky and brittle.
Building application first and using postbuild file copy commands to create a model helps define what the installer should look like.
Installation projects frequently have to consume files from projects that may not even use visual studio at all or a combination of both.
Cons:
Separating the code can lead to an "us vs them" situation between application developers and installation developers. However this can be mitigated by creating a clear understanding of roles and responsibilities. Nothing stops developers from being aware of and contributing to either solution.
A solution is a container that's used to organize one or more related code projects, for example a class library project and a corresponding test project. We'll look at the properties of a project and some of the files it can contain. We'll also create a reference from one project to another.
So if the WIX project relates to other projects in this solution, then add this setup as another project to the your existing solution.
I just downloaded Visual Studio Code last night. What do I do so that Code will generate, say, a Console Application template?
I've read around the web so far I can't find anything telling me how to create a template.
Q: How do I create and run a new project?
A: VS Code doesn't include a traditional File > New Project dialog or
pre-installed project templates. You'll need to add additional
components and scaffolders depending on your development interests.
With scaffolding tools like Yeoman and the multitude of modules
available through the NPM package manager, you're sure to find
appropriate templates and tools to create your projects.
for details: https://code.visualstudio.com/docs/setup/setup-overview
and a question on SO: Run C# Console Application on Visual Studio Code Editor on Windows
I have a common DataAccess Class Library Project. This project needs to be Referenced in multiple Visual Studio Solution.
Currently we are Referencing this DA Library via Folder created in each project called binary.
so whenever there is a change in DataAccess Library project, we have Manually update all the projects that are Referencing this DAL.
I was thinking about creating Single Solution, which will have All the Projects
including DAL & all other Projects that are Referencing it and change the Reference to PRoject Reference DAL from other Projects, instead of File Reference from Binary folder.
Is there any other Better Solution around sharing this DAL ?
The answer is Nuget.
You should package you dal output as a nuget package and push it to a nuget server.a nuget server can be a network share our an application like ProGet.
Preferably you have an automated build do there package and push. That makes it easy.
Then each of your other solutions can take a dependency on that package. When you update it in the Nuget server each of the solutions will notify of a new version that can be used.
So I decided to take a look at this new Visual Studio 14 CTP. When I tried to add a package from Nuget library (Raven Database Server precisely) to my ASP.NET vNext Web Application, it felt like nothing really happened. Not a single piece of solution has changed, and the References remained the same.
I tried adding it manually using my "Project.json" file (as seen in this article), but IntelliSense didn't provide me with any fill. I actually tried it in a lot of different ways, with a whole lot of Nuget packages, with the same result.
Can anybody explain this situation?
ASP.NET vNext supports two targets: .NET 4.5 and CoreCLR. When targeting .NET 4.5 (net45) you can add any existing NuGet reference. When targeting CoreCLR (k10) you can only add NuGet references that support it; today, only some packages support that.
The package that you mention is only available for net45. To add a reference to it, add the package as a dependecy in the net45 section of project.json - just like autofac is added in this file
The entry should be: "RavenDB.Server":"2.5.2879"
PS: the manage NuGet references dialog is not functional for ASP.NET vNext projects in this version of VS
I thought this problem was fixed. I'm using Visual Studio 2013 and it is Entity Framework 6.1. I get the error message: PublicKeyToken=xxxxxx is not marked as serializable.
I thought this was fixed. Is it broken again and if so, is there a workaround?
Thanks.
Here is the complete error message when trying to install into a win32 C++ console application. (Built with default settings, no other adds to new build.)
Error: Type
'Microsoft.VisualStudio.Project.VisualC.VCProjectEngine.VCProjectShim' in Assembly
'Microsoft.VisualStudio.Project.VisualC.VCProjectEngine, Version=12.0.0.0,Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a' is not marked as serializable.
Here is the complete error message when trying to install into a C++ CLR:
(Actually, it's the exact same error message.)
Here is the complete error message when trying to install into a General Empty C++ Project:
(Again, same error message.)
Okay, I can finally figure out what you are doing. You are trying to run Nuget to download and install the Entity Framework into a C++ project. Yes, that's going to be a fail-whale. Nuget acquired the ability to install C++ libraries at version 2.5, but that only works for native libraries. Pure C++, not managed code like EF. Being a relatively new feature, it doesn't do anything to stop you from getting it wrong, it doesn't filter the available packages to the kind that can work in a C++ project.
The step that fails is the final one, download and copying files work okay but then Nuget runs a Powerscript script to modify the project properties. Which, for EF, was written to work in a C# or VB.NET project. The VS extension model for C++ projects (implemented by the VCProjectEngine class as reported in the error message) is too different to permit that script to complete successfully.
Do keep in mind that the odds of using EF in a native C++ projects are zero. You'll only have a smallish shot at it in a C++/CLI project. Starting with a project template in the CLR node is a required first step.
The next one is to fool the Nuget installer, add a dummy C# project to your solution and run Nuget to get EF installed into that project. You'll see it adding an app.config file to the project, you need to do the same in your C++/CLI project. And it adds two EF assemblies that you also need to add to your C++/CLI project:
Right-click the project in the Solution Explorer window, Properties
Select Common Properties + References
Click the Add New Reference button
Click the Browse button
Navigate to the dummy C# project's packages\EntityFramework.6.1.0\lib\net45 directory
Select EntityFramework.dll you see there
Repeat to add EntityFramework.SqlServer.dll there.
Be sure to write C++/CLI code to use it. Beware that you'll have a Eskimo's chance to find any. The much saner approach is to create a C# library that uses EF and use that library in a C++/CLI project.