In Visual Studio 2010, I created a dynamics package project (Y), and a dynamics plugin project (X), following the tutorial here:
http://inogic.blogspot.com/2011/11/crm-2011-developer-toolkit.html#comment-form
The Package Project (Y) references the plugin project (X).
After adding these 2 projects to the solution, I get this error on build:
The item "...\X.csproj" in item list "ProjectReference" does not
define a value for metadata "SilverlightApplication". In order to use
this metadata, either qualify it by specifying
%(ProjectReference.SilverlightApplication), or ensure that all items
in this list define a value for this metadata.
I have no idea how to fix this. Can anybody help ?
I looks like you have used the "Visual Studio Solution Template for Dynamics CRM 2011". This includes a Silverlight application. Generally i would recommend to only use the "Dynamics CRM 2011 Package" project in combination with the different projects you need for your solution.
Anyway - if you right click your CrmPackage project in Solution Explorer you can select "Edit project file". In this file you should find something like this:
<ProjectReference Include="..\SilverlightApplication\SilverlightApplication.csproj">
<Name>SilverlightApplication</Name>
<Project>{0da346e9-f8fc-4f24-92b5-73832c037b3d}</Project>
<Private>False</Private>
<SilverlightApplication>True</SilverlightApplication>
<SilverlightVersion>v4.0</SilverlightVersion>
</ProjectReference>
You could try to remove this section, but remember to do a backup first. After you have edited this file you have to right click your project again and select reload project.
I figured out what the problem was.
Dynamics CRM 2011 Developer Toolkit does not accept virtual folders in the Visual Studio 2010 solution. Each project that is part of the CRM Package must be at top level, directly under the solution.
Otherwise, the error mentioned will pop up.
Related
I'm trying to create a setup project for a WPF application (.NET 5) using VS Community 2019. I've installed the extension for the setup project and I'm following this guide. Since I want to deploy in a self-contained manner I've created a publishing profile and used its relative path for the Publish Items => PublishProfilePath entry in the setup project. However when I try to build I get the following error:
"Could not find the publishing profile ... used in project output group 'Publish Items from ... (Active)"
So is it at all possible to build a self-contained setup project? Also it's confusing that VS says that the "PublishProfilePath" is only used for .NET Core 3 projects whereas the guide mentioned above seems to indicate that it can be used for .NET Core 3 and above.
Any suggestions on this are highly appreciated.
Finally figured it out. The mistake I made was using the wrong path (the "Target location" from the publishing profile):
So the correct way to do this is as follows:
Create a publish profile which is automatically named like this:
Make the following entry in "PublishProfilePath" (don't forget to prepend "Properties\PublishProfiles"):
Then it is possible to build a self-contained installer.
Attempting to create nuget package to upload to our own nuget sever, and would like to eliminate the manual process of creating and editing the nugspec file. Everything I've read, says the setting can be pulled from the project file (if using package reference). And that the settings exist on the Package tab of the project properties window. But that tab is not there.
Using vs 2019, .NetFramework 4.7.2, project is a library, and has been migrated to package reference.
I took an existing project, right clicked the references, and used the migrate option. Package tab is non-existent
I also set the nuget package manager to default to packageReference, and create a new class library.
Package tab also non-existent
The required package (when using non-SDK Style with package reference) nuget.build.tasks.pack has bee added to the references of both projects mentions
Any help would be appreciated
The package tab is only available for SDK style projects. Non-SDK style projects use a different project system in Visual Studio, which doesn't contain that project properties tab. The new project system (on github, the old one is closed source) was initially made to look the same as the old project system, but slowly they're diverging. The Reference/Dependencies node in Solution Explorer is one obvious example, as is the Package tab in the project properties window.
To create the MSBuild properties used by pack, you'll need to manually edit the project file as XML. Within Visual Studio, you need to right click the project in Solution Explorer, select "unload project", now when you single click the project, or right click and select edit, you'll see the project XML. Once done, right click the project again and select reload project. Alternatively, edit it with a text or XML editor outside of Visual Studio, and Visual Studio will detect the change and prompt you to reload the project when you alt-tab back.
My suggestion, however, is to convert your non-SDK style project to an SDK style project. "Standard" class library projects work fine, and I'm not aware of any disadvantages (unless some developers on your team are using Visual Studio 2015 or earlier still), given the non-SDK style project is already using PackageReference. Some other project types might have limited Visual Studio experiences when targeting .NET Framework in an SDK style project. Other project types might not be compatible with SDK style projects at all. However, most people creating NuGet packages are doing so with standard class library projects, which shouldn't have any problems.
There is a "unsupported" tool try-convert to convert non-SDK style projects to SDK style. Personally, I just delete the csproj, create an empty directory, run dotnet new classlib on the console, move the csproj to my existing project's directory, rename the project file, and delete that temporary/empty directory. If you have anything other than .cs files in your project that need explicit entries in the csproj, hand edit the csproj if you're comfortable with msbuild, otherwise load the project in Visual Studio and use the Solution Explorer and Properties windows.
Some people believe that SDK style projects are only for .NET Core or .NET Standard. That's not true, but unfortunately the Visual Studio new project templates give that impression. You will need to create the class library project targeting .NET 5, .NET Standard, or .NET Core. But once the csproj is created, edit the csproj (with SDK style projects it's no longer necessary to unload the project) and change <TargetFramework>net5.0</TargetFramework> to <TargetFramework>net472</TargetFramework>. Another advantage of SDK style projects is it's easy to multi-target, a useful technique to slowly modernize your projects to newer runtimes. Add an s to the XML element name to make it plural, and add extra target frameworks as a semi-colon delimited list <TargetFrameworks>net472;net5.0</TargetFrameworks>. When changing between TargetFramework and TargetFrameworks, Visual Studio should prompt you to reload the project, but I found that it still has some issues. So I suggest closing the solution and opening it again, then everything should work great.
I'm working on a MVC ASP.NET project. The database sql files are in a project of their own so they can be worked on and version controlled but they aren't to be managed by Visual Studio. They used to build and have errors. Rather than working out the errors we simply decided to stop these files building. I achieved this by changing the Build Action of it to None.
I've just upgraded VS to the latest 15.5.4 with various additional installed products and now the sql files are building again despite the build action remaining at None. And giving build errors.
The additional installed products include:
SQL Server Data Tools - 15.1.61710.120
I assume it was upgraded and is behind this problem.
Does anyone know what is causing these files to build when they shouldn't? And how to stop?
A partial answer is to unload the project:
Select project in Solution Explorer
menus > Project > unload project
This requires needing to reload the project to work on it. Which is less than ideal.
To All,
I haven't used a Visual Studio in quite a few years, and don't remember what version I had used. I created 15-20 libraries and 30-40 utilities - all in C.
I recently decided that I wanted to enhance some of the libraries and utilities and acquired Visual Studio 2010. I open an existing project (.dsw) and I get a popup that says "The project ' must be converted to the current ... Convert and open this project?' I click on Yes. I then get a popup that says "A file with the same name ... already exists on disk. Do you want to overwrite the project and its imported sheets?' Again I say Yes.
I go along my way and make a bunch of changes to the project. I click on "Save All." I then close the project and when I reopen, it is like I didn't change anything! I get the same popups again!
I've check the permissions on the directory and files and they should be writable. I have SCOURED the net trying to find out what I am doing wrong to no avail.
Any helpful pointers would be greatly appreciated!
TIA,
je
.dsw extension was used by Visual Studio 6, Visual Studio 2010 project files have extension .vcxproj. The conversion process mentioned in your question creates those new project files. Open them instead of old .dsw
Just downloaded the Silverlight 3 Toolkit and executed the MSI file.
Now I need to reference the Microsoft.Windows.Controls.dll file but don't know where MSI unpacked it. Can't find it at C:\ or in C:\Program Files. Where might it be?
ok, this post says that all the components should be in the toolbox, e.g. DockPanel, they are for Visual Studio 2008 Professional but not for Visual Web Developer 2008 Express (it has some controls but not DockPanel for instance)
Answer:
Ok, the answer is: reboot and restart everything (until then Silverlight got a AG_E_PARSER_BAD_TYPE error, and brought down both Visual Studio versions and Firefox). After restarting everything, it works fine: the controls are automatically in the toolbox so you just have to drag them in, no need referencing the dll anymore as in Silverlight 2.
It didnt automatically add anything for me for Silverlight Beta 4 Toolkit and Visual Studio 2010 Beta 2.
I followed these instructions. My toolkit bin was located :
C:\Program Files\Microsoft SDKs\Silverlight\v4.0\Toolkit
In addition I had to select additional DLLs for additional toolkit items from those described in the article. I also had to check the checkbox to indicate I actually wanted those items.
There must be a better way! Anyone?
Just in case anyone was wondering, I was :-).
There is a start menu group named "Microsoft Silverlight 3 Toolkit March 2009" with all the relevant info. The toolkit assemblies can be found in "C:\Program Files\Microsoft SDKs\Silverlight\v3.0\Toolkit\March 2009\Libraries"
The July 2009 release of the Silverlight Toolkit added a "Open the welcome page" choice at the end of the MSI setup.
The path names for the July release are also slightly different, but using the Welcome page (a link is also added to the Start Menu), you'll always have a quick method to find 'em.
Checking that box will make sure that a page opens up with details about everything that's installed, including links to all the binaries, themes, the documentation, etc.
Also, since the controls are all referenced through the AssemblyFolderEx registry key, you can add a GAC-style reference in your C# or VB.NET project...
<Reference Include="System.Windows.Controls.Input.Toolkit" />
And that will just work when built on a machine with the Silverlight SDK.
Hopefully it's a step in the right direction.