How can I reset Visual Studio's publishing configuration to default? - vb.net

I am just a hobbyist programmer so I am sorry if I am asking a question I should know the answer to. I searched for an answer, but never found it, so I thought I would join and post a question here.
I have some VB 2010 Express code I have written that I wished to deploy from my web page. I used Visual Studio's ClickOnce publishing system and was pleased with the results.
After a couple of versions published I went into the publisher's configuration manager to explore the options.
That was my, uhhh, mistake. I changed many things that I thought would make things nicer for the deployment but screwed up something because now all versions, even previously working versions no longer deploy correctly. If you click for a download and installation, the install starts but the installer complains that there is an error it wants to report to Microsoft.
Is there some way to reset the publish configuration back to it's starting values?
I am running VB on XP with Visual Studio 2010 Express.

I was able to reset the Publish settings for my actual project by comparing the content of the project files for two sample projects, one with publishing and the other one without and identifying which entries were added. I used the FC DOS command to output the differences to a text file (the file extensions were .csproj since mine was a C# project):
fc publish_project.csproj non_publish_project.csproj > diff.txt
I examined diff.txt and found what changed. Deleting the following entries from the real project file will reset the Publish option (do a backup first!):
<IsWebBootstrapper>true</IsWebBootstrapper>
<PublishUrl>ftp://ftpserver.com/</PublishUrl>
<Install>false</Install>
<InstallFrom>Web</InstallFrom>
<UpdateEnabled>true</UpdateEnabled>
<UpdateMode>Foreground</UpdateMode>
<UpdateInterval>7</UpdateInterval>
<UpdateIntervalUnits>Days</UpdateIntervalUnits>
<UpdatePeriodically>false</UpdatePeriodically>
<UpdateRequired>false</UpdateRequired>
<MapFileExtensions>true</MapFileExtensions>
<InstallUrl>http://www.myproduct.net/project1/downloads/</InstallUrl>
<CreateWebPageOnPublish>true</CreateWebPageOnPublish>
<WebPage>publish.htm</WebPage>
<ApplicationRevision>0</ApplicationRevision>
<ApplicationVersion>1.0.0.%2a</ApplicationVersion>
<UseApplicationTrust>false</UseApplicationTrust>
<PublishWizardCompleted>true</PublishWizardCompleted>
<BootstrapperEnabled>true</BootstrapperEnabled>
...
<PropertyGroup>
<TargetZone>LocalIntranet</TargetZone>
</PropertyGroup>
<PropertyGroup>
<GenerateManifests>true</GenerateManifests>
</PropertyGroup>
...
<ItemGroup>
<BootstrapperPackage Include="Microsoft.Net.Client.3.5">
<Visible>False</Visible>
<ProductName>.NET Framework 3.5 SP1 Client Profile</ProductName>
<Install>false</Install>
</BootstrapperPackage>
<BootstrapperPackage Include="Microsoft.Net.Framework.3.5.SP1">
<Visible>False</Visible>
<ProductName>.NET Framework 3.5 SP1</ProductName>
<Install>true</Install>
</BootstrapperPackage>
<BootstrapperPackage Include="Microsoft.Windows.Installer.3.1">
<Visible>False</Visible>
<ProductName>Windows Installer 3.1</ProductName>
<Install>true</Install>
</BootstrapperPackage>
</ItemGroup>

Copying the file ProjectName.vbproj from a very previous version took care of my problem.
I would presume that the other suggestion, creating a new project and copying it's file, should have the same result. Especially if you do not have previous versions.

When you publish, it creates a profile with all the configuration settings.
So, you just have to delete that profile.
Click on "Delete" and it should be reseted.

Related

How to use .NET 6 Preview Generic Math in Visual Studio 2022?

There are several articles explaining the new .NET 6 Preview features of Generic Math, often based on this Microsoft article:
https://devblogs.microsoft.com/dotnet/preview-features-in-net-6-generic-math/
In the preview versions, and the first release of Visual Studio 2022 this works fine. But in Visual Studio 2022 version 17.0.3 and 17.0.4 (the current release) I simply cannot get this to compile.
I actually went back to VS2022 version 17.0.0 to make sure I had correctly followed the article steps. The code compiles just fine. Upgrade to VS2022 version 17.0.3 and the same project fails to build with the error:
Error CS0246 The type or namespace name 'INumber<>' could not be found (are you missing a using directive or an assembly reference?)
Anyone got any ideas? I assume I have to make a further change to the csproj file, but what change?
In the NuGet Package Manager I found the option to upgrade System.Runtime.Experimental to version 6.0.0, which changed the entry in my csproj file from:
<ItemGroup>
<PackageReference Include="System.Runtime.Experimental" Version="6.0.0-preview.7.21377.19" />
</ItemGroup>
to:
<ItemGroup>
<PackageReference Include="System.Runtime.Experimental" Version="6.0.0" />
</ItemGroup>
rebooting doesn't help. Cleaning the solution doesn't help. I am not seeing anything to help me in the release notes for Visual Studio 2022 either.
The complete csproj file, for reference, already containing the extra bits you need, is:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net6.0</TargetFramework>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
<EnablePreviewFeatures>True</EnablePreviewFeatures>
<LangVersion>preview</LangVersion>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="System.Runtime.Experimental" Version="6.0.0" />
</ItemGroup>
</Project>
Step 1
As explained in the blog article you've linked at the top of the question: add
<EnablePreviewFeatures>true</EnablePreviewFeatures>
into a <PropertyGroup> element in your project file.
Step 2
Now the above is confirmed: have you tried the preview version of VS2022 (currently V17.1 Preview 1.1)?
Just tried it: No.
Step 3
See Hans Passant's comment on to the question: need to wait on this (or do you own builds of what is being built to be .NET 7...)
Update for VS 2002 17.2.0 Preview 3.0
With V6.0.2 of System.Runtime.Experimental this now works.
I got the same error with VS2022 17.0.4. Now, VS2022 17.1.0 Preview 1.1 seems to work fine.

NuGet package failing to deploy the actually dll.deploy to IIS

Having an issue getting a dependency to deploy w/ a VB.NET WinForms app. The app runs, but errors when the DLL is referenced/used.. The DLL is not inside the user's install directory upon inspection.
I installed a new NuGet package (first NuGet in this solution) and it works great. I've implemented it, tested locally. Looking at the bin folder (this is in debug), I see the DLLs are all there.. great.
I can publish the application w/ ClickOnce with "No Issues". I am deploying to IIS 8.0 w/ a Web Share. The DLL isn't there though on the web server, either.
The "Application Files..." menu under "Publish" has all CefSharp references as "include", "required", "include" across all cols. This forces ClickOnce to include them as resources right?
Under references in Visual Studio, they're all set to Copy Local = True.
However... when I change Copy Local nothing changes in my GIT history/change history!! Visual Studio sees and recognizes the .vbproj was modified, however there weren't any visible (unicode?) changes. I can commit.
I am on the latest version of Visual Studio, VS2019 16.8.2 for Blazor/ASP.NET Core reasons. Should I try downgrading?
I added a Chromium wrapper based control to replace the generic IE7 Web Control in .NET Framework. I'm working in an .NET 4.6 app. x86.
CefSharp GIT Repo.
https://github.com/cefsharp/cefsharp
I'm using the CefSharp.Common and CefSharp.WinForms namespaces in my application.
Warnings saying unable to publish properties for the DLLS.
Edit: Possible Duplicate: Unable to apply publish properties for item X
Edit2:
Here is an excerpt from my .vbproj
<ItemGroup>
<PublishFile Include="CefSharp">
<Visible>False</Visible>
<Group>
</Group>
<TargetPath>
</TargetPath>
<PublishState>Include</PublishState>
<IncludeHash>True</IncludeHash>
<FileType>Assembly</FileType>
</PublishFile>
<PublishFile Include="CefSharp.Core">
<Visible>False</Visible>
<Group>
</Group>
<TargetPath>
</TargetPath>
<PublishState>Include</PublishState>
<IncludeHash>True</IncludeHash>
<FileType>Assembly</FileType>
</PublishFile>
<PublishFile Include="CefSharp.WinForms">
<Visible>False</Visible>
<Group>
</Group>
<TargetPath>
</TargetPath>
<PublishState>Include</PublishState>
<IncludeHash>True</IncludeHash>
<FileType>Assembly</FileType>
</PublishFile>
<PublishFile Include="FlexCell">
<Visible>False</Visible>
<Group>
</Group>
<TargetPath>
</TargetPath>
<PublishState>Include</PublishState>
<IncludeHash>True</IncludeHash>
<FileType>Assembly</FileType>
</PublishFile>
</ItemGroup>
<ItemGroup>
<WCFMetadata Include="Service References\" />
</ItemGroup>
<ItemGroup>
<PackageReference Include="CefSharp.Common">
<Version>86.0.241</Version>
</PackageReference>
<PackageReference Include="CefSharp.WinForms">
<Version>86.0.241</Version>
</PackageReference>
</ItemGroup>
SOLVED BY: Edit: This didn't fully solve my issue alone but was a hack attempt to bring in all resources, manually, and it worked.
Edit 3: OK None of these solutions worked including downgrading to 16.4 lol that was fun. Please install your required CefLibrary.WinForms etc libraries..
Then build the project.. it needs to actually build.
This generates .dlls in your \bin directory in your file system.
Edit 4: Gave up. Visual Studio 16.8.2 and 16.8.1 are both just outright broken. You can do down the rabbit hole (this is December 2020) but it looks like the visual studio team
https://github.com/dotnet/roslyn/issues/48679
is having issues with references right now. (that one feature that's been the same for 20 years) They don't even have an eta - after they broke a crucial feature - in a enterprise/production product. This wasn't a preview lol. How did this pass unit testing :D
For my use case of CefSharp I needed to load a PDF. I am not directly using an Adobe ActiveX control instead.
Take a look at this request https://github.com/cefsharp/CefSharp/issues/3274
This was very very recent (nov 2020) and he "fixed" it
Move these out to a better place, maybe a "references" folder then actually reference them manually through VS2019 like you would any other .dll.
I'm assuming this is a bug and not the intended workflow since it wasted almost 10 hours of rabbit hole googling nearly. <-- This was in fact a bug.
Solution: There is none. Evidently. On the latest version of everything as of Dec 2nd 2020 - stable and all - your own CefSharp implementation will be broken even when properly setting up to spec of other examples if compiling w/ 16.8.1 or 16.8.2 (but it doesn't seen to be working with 16.6.2 either)
https://github.com/cefsharp/CefSharp/issues/3274

.NET Core RuntimeIdentifier vs TargetFramework

Can someone explain the purpose of this two in csproj file (VS2017):
<TargetFramework>netstandard1.6</TargetFramework>
<RuntimeIdentifier>win7</RuntimeIdentifier>
I just migrated from VS2015 and now can't publish my web api because it looks I should use only one target framework. In addition I can't specify multiple RIDs.
All these changed things make me frustrated. Nothing works from scratch, should overcome something over and over.
I just want developing my web-api on windows, run xUnit tests here and then deploy web-api to run on linux (ubuntu) server.
What I should put in both parameters in csproj ?
Links with good explanation is highly appreciated.
Update1
I have web api with referenced .net core libraries. Everything where migrated from VS2015. Now in root project I have
<TargetFrameworks>netcoreapp1.1;net461</TargetFrameworks>. When I publish via VS2017 I got error:
C:\Program
Files\dotnet\sdk\1.0.3\Sdks\Microsoft.NET.Sdk\buildCrossTargeting\Microsoft.NET.Sdk.targets(31,5):
error : The 'Publish' target is not supported without specifying a
target framework. The current project targets multiple frameworks,
please specify the framework for the published application.
But I have specified target framework in publish as netcoreapp1.1.
OK. Then I updated my csproj with <PropertyGroup Condition="$(TargetFramework)'=='netcoreapp1.1'">
<RuntimeIdentifier>ubuntu.16.10-x64</RuntimeIdentifier>
</PropertyGroup> as suggested below.
But now I even can't build app, get error:
5>C:\Program Files (x86)\Microsoft Visual
Studio\2017\Enterprise\MSBuild\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Sdk.targets(92,5):
error : Assets file '\obj\project.assets.json' doesn't
have a target for '.NETCoreApp,Version=v1.1/ubuntu.16.10-x64'. Ensure
you have restored this project for TargetFramework='netcoreapp1.1' and
RuntimeIdentifier='ubuntu.16.10-x64'.
I just want develop with VS2017 at windows 8.1/windows7 and deploy to ubuntu 16.10.
What I'm doing wrong ?
Update2
I have 8 projects in solution. 3 of them are xUnit tests. Thus we have 5 projects. 4 of these 5 are class libraries and 1 is my web-app.
All 4 class libraries have this:
<TargetFrameworks>netstandard1.6;net461</TargetFrameworks>
<ItemGroup Condition=" '$(TargetFramework)' == 'net461' ">
<Reference Include="System" />
<Reference Include="Microsoft.CSharp" />
</ItemGroup>
My web app:
<TargetFrameworks>netcoreapp1.1;net461</TargetFrameworks>
<ItemGroup Condition=" '$(TargetFramework)' == 'net461' ">
<Reference Include="System" />
<Reference Include="Microsoft.CSharp" />
</ItemGroup>
How to publish my web-app ?
The <TargetFramework> (or <TargetFrameworks> when you want have multiple targets, such as net451, one or multiple netstandard1.x etc). Per <TargetFramework> / <TargetFrameworks> entry one set of assemblies will be created and located inside bin\Debug\<targetframeworkid>).
This is useful, when you want to use a different library in .NET Core (because the library you used only works with full .NET Framework such as 4.5.1) or remove this feature from i.e. .NET Core because it's unsupported.
It is used for both, building and NuGet restore. i.e. you can't use a net451 only library in a .NET Core project (netstandard 1.1 for example - but you can use netstandard1.1 in a net451 project).
<RuntimeIdentifier> / <RuntimeIdentifiers> on the other side is used for NuGet mainly. It tells NuGet which packages you need. For example if you want to target Linux, Mac and Windows, certain assemblies require native libraries (such as encryption. On windows CryptoAPI will be used, but on Linux and Mac you need OpenSSL). This includes non-managed dlls and *.so (Linux) files.
i.e. <RuntimeIdentifiers>win7-x64;win7-x86;ubuntu.16.10-x64</RuntimeIdentifiers> will make nuget restore packages for win7 (both x64 and x86) versions and x64 only for ubuntu. This is required, because when you work on windows you need to download these native libraries too so you deploy/package them with dotnet publish.
Here's a little catch though: When you have a full .NET Framework reference in <TargetFramework> or <TargetFrameworks>, then you must specify a single <RuntimeIdentifier> (singular, not plural <RuntimeIdentifiers>), otherwise you will get an error.
For example:
<PropertyGroup>
<TargetFrameworks>netstandard1.0;net451</TargetFrameworks>
<RuntimeIdentifiers>win7-x64;win7-x86;ubuntu.16.10-x64</RuntimeIdentifiers>
</PropertyGroup>
<!-- This entry will only be used for the .NET Framework 4.5.1 output -->
<PropertyGroup Condition="'$(TargetFramework)' == 'net451'">
<RuntimeIdentifier>win7-x64</RuntimeIdentifier>
</PropertyGroup>
RID is short for Runtime IDentifier. RIDs are used to identify target
operating systems where an application or asset (that is, assembly)
will run. They look like this: "ubuntu.14.04-x64", "win7-x64",
"osx.10.11-x64". For the packages with native dependencies, it will
designate on which platforms the package can be restored.
More in docs
First change to proper RID from win7 to win7-x64 or win7-x86. Next add other RID like ubuntu. For example:
<PropertyGroup>
<TargetFramework>netstandard1.6</TargetFramework>
<RuntimeIdentifier>win7-x64;ubuntu.16.10-x64</RuntimeIdentifier>
</PropertyGroup>
Target framework looking good. For more read docs

How to exclude some stylecop rule in visual studio 2013

I'm using visual studio 2013.
I install stylecop using NuGet Package follow these steps:
https://www.nuget.org/packages/StyleCop.MSBuild/
Previously when I using visual studio 2010, I usually put my custom rules set called Setting.StyleCop file to my solution or project.
How should I implement my custom rules set in VS 2013?
Settings.StyleCop still works as it did previously.
The StyleCop.MsBuild package performs a couple of actions:
1. Stores an instance of StyleCop.exe in the packages directory, this makes it portable between machines, build servers etc.. Namely \packages\StyleCop.MSBuild.4.7.49.1\tools this is pretty much the same you would get with installing it, but its not in program files.
2. Makes changes to the csproj, namely:
<Import Project="..\..\packages\StyleCop.MSBuild.4.7.49.1\build\StyleCop.MSBuild.Targets" Condition="Exists('..\..\packages\StyleCop.MSBuild.4.7.49.1\build\StyleCop.MSBuild.Targets')" />
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
</PropertyGroup>
<Error Condition="!Exists('..\..\packages\StyleCop.MSBuild.4.7.49.1\build\StyleCop.MSBuild.Targets')" Text="$([System.String]::Format('$(ErrorText)', '..\..\packages\StyleCop.MSBuild.4.7.49.1\build\StyleCop.MSBuild.Targets'))" />
</Target>
All this basically does is point at the targets file so that it runs stylecop and adds in some requires for the package to be there before building.
What you need to do to use StyleCop.Settings
Copy it into the root of your solution, or the project file, then it should get picked up as usual. The easiest way is just to copy it from \packages\StyleCop.MSBuild.4.7.49.1\tools

Overriding MSBuildExtensionsPath in the MSBuild task is flaky

This is already cross-posted at MS Connect:
https://connect.microsoft.com/VisualStudio/feedback/details/560451
I am attempting to override the property $(MSBuildExtensionsPath) when building a solution containing a C# web application project via msbuild. I am doing this because a web application csproj file imports the file "$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets". This file is installed by Visual Studio to the standard $(MSBuildExtensionsPath) location (C:\Program Files\MSBuild). I would like to eliminate the dependency on this file being installed on the machine (I would like to keep my build servers as "clean" as possible). In order to do this, I would like to include the Microsoft.WebApplication.targets in source control with my project, and then override $(MSBuildExtensionsPath) so that the csproj will import this included version of Microsoft.WebApplication.targets. This approach allows me to remove the dependency without requiring me to manually modify the web application csproj file.
This scheme works fine when I build my solution file from the command line, supplying the custom value of $(MSBuildExtensionsPath) at the command line to msbuild via the /p flag. However, if I attempt to build the solution using the MSBuild task in a custom msbuild project file (overriding MSBuildExtensionsPath using the "Properties" attribute), it fails because the web app csproj file is attempting to import the Microsoft.WebApplication.targets from the "standard" Microsoft.WebApplication.targets location (C:\Program Files\MSBuild). Notably, if I run msbuild using the "Exec" task in my custom project file, it works. Even more notably, the FIRST time I run the build using the "MSBuild" task AFTER I have run the build using the "EXEC" task (or directly from the command line), the build works.
Has anyone seen behavior like this before? Am I crazy? Is anyone aware of the root cause of this problem, a possible workaround, or whether this is a legitimate bug in MSBuild?
Steps to Reproduce:
1) Create a new empty solution in MSVS 2008 (Fake.sln)
2) Add a new C# web application to the solution (WebApplication1.csproj)
3) Close MSVS
4) Copy the contents of "C:\Program Files\MSBuild\" to a directory called "MSBuildExtensions" in the directory containing your solution.
5) rename the directory "C:\Program Files\MSBuild\Microsoft\VisualStudio\v9.0\WebApplications" so that WebApplication1.csproj will not be able to import Microsoft.WebApplication.targets from that location.
6) Create a custom MSBuild project file called "TestBuild.proj" in the same directory as the solution. It should have the following content:
<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="BuildMSBuild">
<PropertyGroup>
<MSBuildExtensionsPath>$(MSBuildProjectDirectory)\MSBuildExtensions\</MSBuildExtensionsPath>
<BuildThis>Fake.sln</BuildThis>
</PropertyGroup>
<Target Name="BuildMSBuild">
<MSBuild Projects="$(BuildThis)" Properties="MSBuildExtensionsPath=$(MSBuildExtensionsPath);" Targets="Clean" />
<MSBuild Projects="$(BuildThis)" Properties="MSBuildExtensionsPath=$(MSBuildExtensionsPath);"/>
</Target>
</Project>
7) execute "msbuild TestBuild.proj" from a MSVS command prompt (note: the build may succeed the first time, but will fail if you run more than once)
Did you try setting the environment variable MSBuildExtensionPath in the CMD prompt and then running your build?
For example:
C:\> SET MSBuildExtensionsPath=C:\My\MSBuild\Extensons
Then on this project file:
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="Build">
<Message Text='MSBuildExtensionsPath="$(MSBuildExtensionsPath)"' />
</Target>
</Project>
you will get the following output:
c:\Users\chuckeng\Desktop\ConsoleApplication1>"C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe" my.proj
Microsoft (R) Build Engine Version 3.5.30729.4926
[Microsoft .NET Framework, Version 2.0.50727.4927]
Copyright (C) Microsoft Corporation 2007. All rights reserved.
Build started 6/25/2010 1:04:05 PM.
Project "c:\my.proj" on node 0 (default targets).
MSBuildExtensionsPath="C:\My\MSBuild\Extensons"
Done Building Project "c:\my.proj" (default targets).
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:00.03
This works from v4.0 as well. Although, support is generally better in v4.0 for things like this. And, v4.0 is 100% backward compatible (bugs not withstanding). So, you can build your v3.5 and prior projects with v4.0. Just select ToolsVersion 3.5.
msbuild my.proj /tv:3.5
Hope this helps...
Chuck England
Visual Studio
Program Manager - MSBuild
This is a bug in MSBuild 3.5 but it is fixed in MSBuild 4.
If you can, switch to MSBuild 4 (you still can compile your 3.5 projects), otherwise you'll have to override the property in the project file.
It works fine if you override MSBuildExtensionsPath directly in the web app .csproj file.
<PropertyGroup>
<MSBuildExtensionsPath>C:\Users\madgnome\Desktop\msbuild</MSBuildExtensionsPath>
<!-- It works too with relative path -->
<!--<MSBuildExtensionsPath>..\msbuild</MSBuildExtensionsPath>-->
</PropertyGroup>
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
Don't know if this might help anyone in the future, but I was able to use the following at the top of my file and it works as I would expect in both 32 and 64 bit build environments.
<PropertyGroup>
<MSBuildExtensionsPath Condition=" '$(MSBuildExtensionsPath64)' != '' ">$(MSBuildExtensionsPath64)</MSBuildExtensionsPath>
</PropertyGroup>
<Import Project="$(MSBuildExtensionsPath)\ExtensionPack\4.0\MSBuild.ExtensionPack.tasks"/>